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1 . The applicant is hereby notified that this International Preliminary Examining Authority transmits herewith the 
international preliminary examination report and its annexes, if any, established on the international application. 

2. A copy of the report and its annexes, if any, is being transmitted to the International Bureau for communication 
to all the elected Offices. 

3. Where required by any of the elected Offices, the International Bureau will prepare an English translation of the 
report (but not of any annexes) and will transmit such translation to those Offices. 

4. REMINDER 

The applicant must enter the national phase before each elected Office by performing certain acts (filing 
translations and paying national fees) within 30 months from the priority date (or later in some Offices) (Article 
39(1)) (see also the reminder sent by the International Bureau with Form PCT/IB/301). 

Where a translation of the international application must be furnished to an elected Office, that translation must 
contain a translation of any annexes to the international preliminary examination report. It is the applicant's 
responsibility to prepare and furnish such translation directly to each elected Office concerned. 

For further details on the applicable time limits and requirements of the elected Offices, see Volume II of the 
PCT Applicant's Guide. 
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Applicant's or agent's file reference 

PAT98101*PCT 


FOR FURTHER ACTION See paragraphs 1 and 4 below 


International application No. 

PCT/EP 99/07718 


International filing date 
(day/month/year) ^ ^ j j ggg 


Applicant 

NOKIA OY et al . 



1 . Q£] The applicant is hereby notified that the International Search Report has been established and is transmitted herewith. 
Filing of amendments and statement under Article 19: 

The applicant is entitled, if he so wishes, to amend the claims of the International Application (see Rule 46): 

When? The time limit for filing such amendments is normally 2 months from the date of transmittal of the 
International Search Report; however, for more details, see the notes on the accompanying sheet. 



Where? Directly to the 



International Bureau of WIPO 
34, chemin des Colombettes 
1 21 1 Geneva 20, Switzerland 
Fascimile No. : (41 -22) 740.14.35 



For more detailed instructions, see the notes on the accompanying sheet. 

2. I — | The applicant is hereby notified that no International Search Report will be established and that the declaration under 
' — I Article 1 7(2)(a) to that effect is transmitted herewith. 

3. Q With regard to the protest against payment of (an) additional fee(s) under Rule 40.2, the applicant is notified that: 

□ the protest together with the decision thereon has been transmitted to the International Bureau together with the 
applicant's request to forward the texts of both the protest and the decision thereon to the designated Offices. 

[ | no decision has been made yet on the protest; the applicant will be notified as soon as a decision is made. 

4. Further action(s): The applicant is reminded of the following: 

Shortly after 18 months from the priority date, the international application will be published by the International Bureau. 
If the applicant wishes to avoid or postpone publication, a notice of withdrawal of the international application, or of the 
priority claim, must reach the International Bureau as provided in Rules 90o/s.1 and 90b/"s.3, respectively, before the 
completion of the technical preparations for international publication. 

Within 19 months from the priority date, a demand for international preliminary examination must be filed if the applicant 
wishes to postpone the entry into the national phase until 30 months from the priority date (in some Offices even later). 

Within 20 months from the priority date, the applicant must perform the prescribed acts for entry into the national phase 
before all designated Offices which have not been elected in the demand or in a later election within 1 9 months from the 
priority date or could not be elected because they are not bound by Chapter II. 



Name and mailing address of the International Searching Authority 
European Patent Office, P.B. 581 8 Patentlaan 2 
^111 NL-2280 HV Rijswijk 

SJJi Tel. (+31-70) 340-2040, Tx. 31 651 epo nl, 
Fax: (+31 -70) 340-3016 
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Form PCT/ISA/220 (July 1998) 



NOTES TO FORM PCT/ISA/220 



These Notes are intended to give the basic instructions concerning the filing of amendments under article 19. The 
Notes are based on the requirements of the Patent Cooperation Treaty, the Regulations and the Administrative Instructions 
under that Treaty. In case of discrepancy between these Notes and those requirements, the latter are applicable. For more 
detailed information, see also the PCT Applicant's Guide, a publication of WIPO. 

In these Notes, "Article", "Rule", and "Section" refer to the provisions of the PCT, the PCT Regulations and the PCT 
Administrative Instructions, respectively. 



INSTRUCTIONS CONCERNING AMENDMENTS UNDER ARTICLE 19 



The applicant has, after having received the international search report, one opportunity to amend the claims of the 
international application. It should however be emphasized that, since all parts of the international application (claims, 
description and drawings) may be amended during the international preliminary examination procedure, there is usually 
no need to file amendments of the claims under Article 1 9 except where, e.g. the applicant wants the latter to be published 
for the purposes of provisional protection or has another reason for amending the claims before international publication. 
Furthermore, rt should be emphasized that provisional protection is available in some States only. 



What parts of the International application may be amended? 

Under Article 1 9, only the claims may be amended. 

During the international phase, the claims may also be amended (or further amended) under Article 34 before 
the International Preliminary Examining Authority. The description and drawings may only be amended under 
Article 34 before the International Examining Authority. 

Upon entry into the national phase, all parts of the international application may be amended under Article 28 
or, where applicable, Article 41 . 



When? Within 2 months from the date of transmittal of the international search report or 1 6 months from the priority 

date, whichever time limit expires later. It should be noted, however, that the amendments will be considered 
as having been received on time if they are received by the International Bureau after the expiration of the 
applicable time limit but before the completion of the technical preparations for international publication 
(Rule 46.1). 



Where not to file the amendments? 

The amendments may only be filed with the International Bureau and not with the receiving Office or the 
International Searching Authority (Rule 46.2). 

Where a demand for international preliminary examination has been/is filed, see below. 



How? Either by cancelling one or more entire claims, by adding one or more new claims or by amending the text of 

one or more of the claims as filed. 

A replacement sheet must be submitted for each sheet of the claims which, on account of an amendment or 
amendments, differs from the sheet originally filed. 

All the claims appearing on a replacement sheet must be numbered in Arabic numerals. Where a claim is 
cancelled, no renumbering of the other claims is required. In all cases where claims are renumbered, they must 
be renumbered consecutively (Administrative Instructions, Section 205(b)). 

The amendments must be made in the language in which the international application is to be published. 



What documents must/may accompany the amendments? 
Letter (Section 205(b)): 

The amendments must be submitted with a letter. 

The letter will not be published with the international application and the amended claims. It should not be 
confused with the "Statement under Article 19(1)° (see below, under "Statement under Article 1 9(1)"). 

The letter must be in English or French, at the choice of the applicant. However, if the language of the 
international application is English, the letter must be In English; if the language of the international application 
is French, the letter must be in French. 
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NOTES TO FORM PCT/ISA/220 (continued) 



The letter must indicate the differences between the claims as filed and the claims as amended. It must, in 
particular, indicate, in connection with each claim appearing tn the international application (it being understood 
that identical indications concerning several claims may be grouped) ,whether 

(i) the claim is unchanged; 

(ii) the claim is cancelled; 

(iii) the claim is new; 

(iv) the claim replaces one or more claims as filed; 

(v) the claim is the result of the division of a claim as filed. 



The following examples illustrate the manner in which amendments must be explained in the 
accompanying letter: 

1 . [Where originally there were 48 claims and after amendment of some claims there are 51]: 
"Claims 1 to 29, 31 , 32, 34, 35, 37 to 48 replaced by amended claims bearing the same numbers; 
claims 30, 33 and 36 unchanged; new claims 49 to 51 added." 

2. [Where originally there were 1 5 claims and after amendment of all claims there are 1 1 ]: 
"Claims 1 to 15 replaced by amended claims 1 to 1 1 ." 

3. [Where originally there were 14 claims and the amendments consist in cancelling some claims and in adding 
new claims]: 

"Claims 1 to 6 and 1 4 unchanged; claims 7 to 1 3 cancelled; new claims 15,16 and 1 7 added." or 
"Claims 7 to 13 cancelled; new claims 1 5, 16 and 17 added; all other claims unchanged." 

4. [Where various kinds of amendments are made]: 

"Claims 1-10 unchanged; claims 11 to 13, 18 and 19 cancelled; claims 14, 15 and 16 replaced by amended 
claim 14; claim 17 subdivided into amended claims 15, 16 and 17; new claims 20 and 21 added." 



"Statement under article 19(1)" (Rule 46.4) 

The amendments may be accompanied by a statement explaining the amendments and indicating any impact 
that such amendments might have on the description and the drawings (which cannot be amended under 
Article 19(1 )). 

The statement will be published with the international application and the amended claims. 
It must be in the language in which the international application is to be published. 

It must be brief, not exceeding 500 words if in English or if translated into English. 

It should not be confused with and does not replace the letter indicating the differences between the claims 
as filed and as amended. It must be filed on a separate sheet and must be identified as such by a heading, 
preferably by using the words "Statement under Article 1 9(1)." 

It may not contain any disparaging comments on the international search report or the relevance of citations 
contained in that report. Reference to citations, relevant to a given claim, contained in the international search 
report may be made only in connection with an amendment of that claim. 



Consequence if a demand for international preliminary examination has already been filed 

If, at the time of filing any amendments and any accompanying statement, under Article 19, a demand for 
international preliminary examination has already been submitted, the applicant must preferably, at the time of 
filing the amendments (and any statement ) with the International Bureau, also file with the International 
Preliminary Examining Authority a copy of such amendments (and of any statement) and, where required, a 
translation of such amendments for the procedure before that Authority (see Rules 55.3(a) and 62.2, first 
sentence). For further information, see the Notes to the demand form (PCT/I PEA/401). 



Consequence with regard to translation of the international application for entry into the national phase 

The applicant's attention is drawn to the fact that, upon entry into the national phase, a translation of the 
claims as amended under Article 19 may have to be furnished to the designated/elected Offices, instead of, or 
in addition to, the translation of the claims as filed. 

For further details on the requirements of each designated/elected Office, see Volume II of the PCT Applicant's 
Guide. 
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PATENT COOPERATION TREATY 

PCT 



INTERNATIONAL SEARCH REPORT 

(PCT Article 1 8 and Rules 43 and 44) 



Applicant's or agent's file reference 

PAT98101*PCT 


FOR FURTHER 
ACTION 


Transmittal of International Search Report 
10) as well as, where applicable, item 5 below. 


International application No. 

PCT/EP 99/07718 


International filing date (day/month/year) 

27/08/1999 


(Earliest) Priority Date (day/month/year) 

28/08/1998 


Applicant 

NOKIA 0Y et al . 



This International Search Report has been prepared by this International Searching Authority and is transmitted to the applicant 
according to Article 1 8. A copy is being transmitted to the Internationa! Bureau. 



sheets. 



This International Search Report consists of a total of b 

[X] It is also accompanied by a copy of each prior art document cited in this report. 



Basis of the report 

a. With regard to the language, the international search was carried out on the basis of the international application in the 
language in which it was filed, unless otherwise indicated under this item. 



□ 



the international search was carried out on the basis of a translation of the international application furnished to this 
Authority (Rule 23.1 (b)). 

With regard to any nucleotide and/or amino acid sequence disclosed in the international application, the international search 
was carried out on the basis of the sequence listing : 

contained in the international application in written form. 



□ 
□ 
□ 
□ 
□ 

□ 



filed together with the international application in computer readable form, 
furnished subsequently to this Authority in written form, 
furnished subsequently to this Authority in computer readble form. 

the statement that the subsequently furnished written sequence listing does not go beyond the disclosure in the 
international application as filed has been furnished. 

the statement that the information recorded in computer readable form is identical to the written sequence listing has been 
furnished 



2. 
3. 



| | Certain claims were found unsearchable (See Box I). 
PT| Unity of invention is lacking (see Box II). 



4. With regard to the title, 

[X[ the text is approved as submitted by the applicant. 

[ [ the text has been established by this Authority to read as follows: 



5 . With regard to the abstract, 

nCI the text is approved as submitted by the applicant. 

H the text has been established, according to Rule 38.2(b), by this Authority as it appears in Box III The applicant may, 
I I W ithin one month from the date of mailing of this international search report, submit comments to this Authonty. 

6. The figure of the drawings to be published with the abstract is Figure No. 14 

\T\ as suggested by the applicant. □ None of the fi 9 ures ' 

| | because the applicant failed to suggest a figure. 

[ [ because this figure better characterizes the invention. 
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INTERNATIONAL SEARCH REPORT 



Intbi national application No. 

PCT/EP 99/07718 



Box I Observations where certain claims were found unsearchable (Continuation of item 1 of first sheet) 

This International Search Report has not been established in respect of certain claims under Article 17(2)(a) for the following reasons: 
1. | | Claims Nos.: 

because they relate to subject matter not required to be searched by this Authority, namely: 



2. | | Claims Nos.: 

because they relate to parts of the International Application that do not comply with the prescribed requirements to such 
an extent that no meaningful International Search can be carried out, specifically: 



3. | | Claims Nos.: 

because they are dependent claims and are not drafted in accordance with the second and third sentences of Rule 6.4(a). 

Box II Observations where unity of invention is lacking (Continuation of item 2 of first sheet) 

This International Searching Authority found multiple inventions in this international application, as follows: 

see additional sheet 



1 . I w I As all required additional search fees were timely paid by the applicant, this International Search Report covers all 
searchable claims. 



2. | | As ail searchable claims could be searched without effort justifying an additional fee, this Authority did not invite payment 
of any additional fee. 



3. I I As only some of the required additional search fees were timely paid by the applicant, this International Search Report 
' ' covers only those claims for which fees were paid, specifically claims Nos.: 



4. | | No required additional search fees were timely paid by the applicant. Consequently, this International Search Report is 
restricted to the invention first mentioned in the claims; it is covered by claims Nos.: 



Remark on Protest 




The additional search fees were accompanied by the applicant's protest. 
No protest accompanied the payment of additional search fees. 



Form PCT/ISA/210 (continuation of first sheet (1)) (July 1998) 



International Application No. PCT£P 99 £7718 



FURTHER INFORMATION CONTINUED FROM PCT/ISA/ 210 



This International Searching Authority found multiple (groups of) 
inventions in this international application, as follows: 

1. Claims: 1-15 

A method and system for supporting the quality of service in 
packet data transmission, where transmission is in radio 
flows, where the appropriate radio flow for transmission of 
packets is selected from a selection of radio flows having 
different quality of service characteristics, and where 
packets are provided with radio flow identifiers 
representative of quality of service characteristics. 



2. Claims: 16-19 

A method and system for supporting the quality of service in 
packet data transmission, where transmission is in radio 
flows, where the appropriate radio flow for transmission of 
packets is selected from a number of radio flows having 
different quality of service characteristics, and where 
queing and packet scheduling is performed. 
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INTERNATIONAL SEARCH REPORT 

(PCT Article 18 and Rules 43 and 44) 



Applicant's or agent's file reference 

PAT98101*PCT 


pQp FURTHER see Notification of Transmittal of International Search Report 

(Form PCT/ISA/220) as well as, where applicable, item 5 below. 

ACTION 


International application No. 


International filing date (day/month/year) 


(Earliest) Priority Date (day/month/year) 


PCT/EP 99/07718 


27/08/1999 


28/08/1998 


Applicant 






NOKIA 0Y et al . 







This International Search Report has been prepared by this International Searching Authority and is transmitted to the applicant 
according to Article 1 8. A copy is being transmitted to the International Bureau. 



sheets. 



This International Search Report consists of a total of b 

| X | It is also accompanied by a copy of each prior art document cited in this report. 



1 . Basis of the report 

a. With regard to the language, the international search was carried out on the basis of the international application in the 
language in which it was filed, unless otherwise indicated under this item. 

I I the international search was carried out on the basis of a translation of the international application furnished to this 
' — ' Authority (Rule 23.1(b)). 

b. With regard to any nucleotide and/or amino acid sequence disclosed in the international application, the international search 
was carried out on the basis of the sequence listing : 
| | contained in the international application in written form. 

filed together with the international application in computer readable form, 
furnished subsequently to this Authority in written form, 
furnished subsequently to this Authority in computer readbte form. 

the statement that the subsequently furnished written sequence listing does not go beyond the disclosure in the 
international application as filed has been furnished. 

the statement that the information recorded in computer readable form is identical to the written sequence listing has been 
furnished 



□ 
□ 
□ 
□ 

□ 



2. Certain claims were found unsearchable (See Box I). 

3. [X] Unity of invention is lacking (see Box II). 

4. With regard to the title, 

[X] the text is approved as submitted by the applicant. 

| | the text has been established by this Authority to read as follows: 



With regard to the abstract, 

|X| the text is approved as submitted by the applicant, 
the text has been established, according to Rule 3 

within one month from the date of mailing of this international search report, submit comments to this Authority. 
6. The figure of the drawings to be published with the abstract is Figure No. Jj4. 



j — | the text has been established, according to Rule 38.2(b), by this Authority as it appears in Box III. The applicant may, 



|X| as suggested by the applicant. Q None of the figures. 

| | because the applicant failed to suggest a figure. 

| | because this figure better characterizes the invention. 
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Box I Observations where certain claims were found unsearchable (Continuation of item 1 of first sheet) 

This International Search Report has not been established in respect of certain claims under Article 17(2)(a) for the following reasons: 
1. | | Claims Nos.: 

because they relate to subject matter not required to be searched by this Authority, namely: 



| | Claims Nos.: 

because they relate to parts of the International Application that do not comply with the prescribed requirements to such 
an extent that no meaningful International Search can be carried out, specifically: 



3. | I Claims Nos.: 

because they are dependent claims and are not drafted in accordance with the second and third sentences of Rule 6.4(a). 

Box II Observations where unity of invention is tacking (Continuation of item 2 of first sheet) 

This International Searching Authority found multiple inventions in this international application, as follows: 

see additional sheet 



1. I y I As all required additional search fees were timely paid by the applicant, this International Search Report covers all 
L-*— ' searchable claims. 

2. | | As all searchable claims could be searched without effort justifying an additional fee, this Authority did not invite payment 

of any additional fee. 



3. I I As only some of the required additional search fees were timely paid by the applicant, this International Search Report 
' ' covers only those claims for which fees were paid, specifically claims Nos.: 



4. | | No required additional search fees were timely paid by the applicant. Consequently, this International Search Report is 
restricted to the invention first mentioned in the claims; it is covered by claims Nos.: 



Remark on Protest [ | The additional search fees were accompanied by the applicant's protest. 

| X | No protest accompanied the payment of additional search fees. 
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International Application No. PCTVEP 99 £7718 



FURTHER INFORMATION CONTINUED FROM PCT/ISA/ 210 



This International Searching Authority found multiple (groups of) 
inventions in this international application, as follows: 

1. Claims: 1-15 

A method and system for supporting the quality of service in 
packet data transmission, where transmission is in radio 
flows, where the appropriate radio flow for transmission of 
packets is selected from a selection of radio flows having 
different quality of service characteristics, and where 
packets are provided with radio flow identifiers 
representative of quality of service characteristics. 



2. Claims: 16-19 

A method and system for supporting the quality of service in 
packet data transmission, where transmission is in radio 
flows, where the appropriate radio flow for transmission of 
packets is selected from a number of radio flows having 
different quality of service characteristics, and where 
queing and packet scheduling is performed. 



INTERNATIONAL SEARCH REPORT 



InterMijcnal Application No 

pd^> 99/07718 



A. CLASSIFICATION OF SUBJECT MATTER 

IPC 7 H04L12/56 H04Q7/38 



According to International Patent Classification (IPC) or to both national classification and IPC 



B. FIELDS SEARCHED 



Minimum documentation searched {classification system followed by classification symbols) 

IPC 7 H04L H04Q 



Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched 



Electronic data base consulted during the international search (name of data base and, where practical, search terms used) 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category ° CitaKon of document, with indication, where appropriate, of the relevant passages 




Relevant to claim No. 



WO 94 28683 A (BRITISH TELECOMM) 
8 December 1994 (1994-12-08) 
page 1, line 2 -page 4, line 3 
page 6, 1 ine 3 - 1 ine 39 
page 8, line 33 -page 10, line 32 
page 14, line 1 - line 17 



1,4,7,10 



2,3,5,6, 

8,9,11, 

12 

16-19 



-/- 



Further documents are listed in the continuation of box C. 



Patent family members are listed in annex. 



° Special categories of cited documents : 

"A" document defining the general state of the art which is not 

considered to be of particular relevance 
"E" earlier document but published on or after the international 

filing date 

"L" document which may throw doubts on priority claim(s) or 
which is cited to establish the publication date of another 
citation or other special reason (as specified) 

"O" document referring to an oral disclosure, use, exhibition or 
other means 

"P" document published prior to the international filing date but 
later than the priority date claimed 



"T" later document published after the international filing date 
or priority date and not in conflict with the application but 
cited to understand the principle or theory underlying the 
invention 

"X" document of particular relevance; the claimed invention 
cannot be considered novel or cannot be considered to 
involve an inventive step when the document is taken alone 

"Y" document of particular relevance; the claimed invention 

cannot be considered to involve an inventive step when the 
document is combined with one or more other such docu- 
ments, such combination being obvious to a person skilled 
in the art. 

document member of the same patent family 



Date of the actual completion of the international search 



19 June 2000 



Date of mailing of the international search report 



29. 06. 2000 



Name and mailing address of the ISA 

European Patent Office, P.B. 5818 Patentlaan 2 
NL - 2280 HV Rijswijk 
Tel. (+31-70) 340-2040, Tx. 31 651 epo nl, 
Fax: (+31-70) 340-3016 



Authorized officer 



Vaskimo, K 



Form PCT/ISA/210 (second sheet) (July 1992) 



page 1 of 3 



INTERNATIONAL SEARCH REPORT 



Inter^^tonal Application No 

pd^> 



99/07718 



C.(Continuation) DOCUMENTS CONSIDERED TO BE RELEVANT 


Category ° 
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Relevant to claim No. 


X 


US 5 530 909 A (SIMON GEORGES-HENRI ET 


1,7 




AL) 25 June 1996 (1996-06-25) 






s column 1, line 8 -column 2, line 17 






column 2, line 65 -column 3, line 36 






column 5, line 8 - line 19 






claims 1,3-7 




Y 




2,3,5,6, 






8,9,11, 






12 


A 




16-19 


X 


/ EP 0 757 500 A (NOKIA MOBILE PHONES LTD) 


1,4,7, 




5 February 1997 (1997-02-05) 


10,13-15 




abstract 






column 1, line 3 -column 3, line 52 






column 4, line 28 -column 5, line 25 






column 6, line 26 - line 36 




Y 


2,3,5,6, 




J 


8,9,11, 






12 


X / 


f FIGUEIRA ET AL: "REMOTE-QUEUEING MULTIPLE 


16-19 




ACCESS (RQMA): PROVIDING QUALITY OF 






SERVICE FOR WIRELESS COMMUNICATIONS" 






PROCEEDINGS IEEE INFOCOM. THE CONFERENCE 






ON COMPUTER COMMUNICATIONS, US, NEW YORK, 






NY: IEEE, 1998, pages 307-314, XP000854206 






ISBN: 0-7803-4384-0 






abstract 






paragraph '0001! 






paragraph '2.1.2! 






paragraph '03.2! 






tables 1,2 




A 




1,7,13 




>\ 

/ W0 97 36405 A (NOKIA TELECOMMUNICATIONS 0Y 


16-19 




;HUUSKO SAMI (FI); KARI HANNU H (FI)) 






2 October 1997 (1997-10-02) 






abstract 






page 1, line 1 -page 5, line 35 






page 7, line 26 -page 9, line 17 
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A 




1,5,7,11 


x U 


GB 2 297 457 A (MOTOROLA ISRAEL LTD) 
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31 July 1996 (1996-07-31) 






page 1, line 5 -page 4, line 37 






page 5, line 16 -page 7, line 9 






page 8, line 15 -page 9, line 13 






page 13, line 1 - line 15 
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Category • Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



EP 0 835 009 A (TOKYO SHIBAURA ELECTRIC 
CO) 8 April 1998 (1998-04-08) 



2,3,5,6, 

8,9,11, 

12 
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and is transmitted to the applicant according to Article 36. 

2. This REPORT consists of a total of 10 sheets, including this cover sheet. 

□ This report is also accompanied by ANNEXES, i.e. sheets of the description, claims and/or drawings which have 
been amended and are the basis for this report and/or sheets containing rectifications made before this Authority 
(see Rule 70.16 and Section 607 of the Administrative Instructions under the PCT). 

These annexes consist of a total of sheets. 
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VI 
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VII 


IS 


VIII 





Lack of unity of invention 

Reasoned statement under Article 35(2) with regard to novelty, inventive step or industrial applicability; 
citations and explanations suporting such statement 

Certain documents cited 

Certain defects in the international application 
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INTERNATIONAL PRELIMINARY 
EXAMINATION REPORT 



International application No. PCT/EP99/0771 8 



I. Basis of the report 

1 . This report has been drawn on the basis of (substitute sheets which have been furnished to the receiving Office in 
response to an invitation under Article 14 are referred to in this report as "originally filed" and are not annexed to 
the report since they do not contain amendments (Rules 70. 16 and 70.17).): 
Description, pages: 

1 -67 as originally filed 

Claims, No.: 

1-19 as originally filed 

Drawings, sheets: 

1/18-18/18 as originally filed 



2. With regard to the language, all the elements marked above were available or furnished to this Authority in the 
language in which the international application was filed, unless otherwise indicated under this item. 

These elements were available or furnished to this Authority in the following language: , which is: 

□ the language of a translation furnished for the purposes of the international search (under Rule 23.1(b)). 

□ the language of publication of the international application (under Rule 48.3(b)). 

□ the language of a translation furnished for the purposes of international preliminary examination (under Rule 
55.2 and/or 55.3). 

3. With regard to any nucleotide and/or amino acid sequence disclosed in the international application, the 
international preliminary examination was carried out on the basis of the sequence listing: 

□ contained in the international application in written form. 

□ filed together with the international application in computer readable form. 

□ furnished subsequently to this Authority in written form. 

□ furnished subsequently to this Authority in computer readable form. 

□ The statement that the subsequently furnished written sequence listing does not go beyond the disclosure in 
the international application as filed has been furnished. 

□ The statement that the information recorded in computer readable form is identical to the written sequence 
listing has been furnished. 

4. The amendments have resulted in the cancellation of: 

□ the description, pages: 

□ the claims, Nos.: 
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□ 



the drawings, 



sheets: 



5. □ This report has been established as if (some of) the amendments had not been made, since they have been 

considered to go beyond the disclosure as filed (Rule 70.2(c)): 

(Any replacement sheet containing such amendments must be referred to under item 1 and annexed to this 
report.) 

6. Additional observations, if necessary: 

IV. Lack of unity of invention 

1 . In response to the invitation to restrict or pay additional fees the applicant has: 

□ restricted the claims. 

□ paid additional fees. 

□ paid additional fees under protest. 

H neither restricted nor paid additional fees. 

2. □ This Authority found that the requirement of unity of invention is not complied and chose, according to Rule 

68.1 , not to invite the applicant to restrict or pay additional fees. 

3. This Authority considers that the requirement of unity of invention in accordance with Rules 13.1 , 13.2 and 13.3 is 

□ complied with. 

K not complied with for the following reasons: 
see separate sheet 

4. Consequently, the following parts of the international application were the subject of international preliminary 
examination in establishing this report: 

□ all parts. 

K the parts relating to claims Nos. 1 -1 5. 

V. Reasoned statement under Article 35(2) with regard to novelty, inventive step or industrial applicability; 
citations and explanations supporting such statement 



1. Statement 



Novelty (N) 



Yes: 
No: 



Claims 

Claims 1,7,13,15 



Inventive step (IS) 



Yes: 
No: 



Claims 
Claims 1-15 
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Industrial applicability (IA) Yes: Claims 1 -1 5 

No: Claims 



2. Citations and explanations 
see separate sheet 



VII. Certain defects in the international application 

The following defects in the form or contents of the international application have been noted: 
see separate sheet 



VIII. Certain observations on the international application 

The following observations on the clarity of the claims, description, and drawings or on the question whether the 
claims are fully supported by the description, are made: 
see separate sheet 
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IV. Lack of unity of invention 

1 . The International Preliminary Examining Authority agrees with the International 
Search Authority, which found multiple (groups of) inventions in this international 
application which are the following: 

1. Claims: 1-15 

A method and system for supporting the quality of service in packet data 
transmission, where transmission is in radio flows, where the appropriate radio 
flow for transmission of packets is selected from a selection of radio flows having 
different quality of service characteristics, and where packets are provided with 
radio flow identifiers representative of quality of service characteristics. 

2. Claims: 16-19 

A method and system for supporting the quality of service in packet data 
transmission where transmission is in radio flows, where the appropriate radio 
flow for transmission of packets is selected from a number of radio flows having 
different quality of service characteristics, and where queuing and packet 
scheduling is performed. 

2. The two inventions could be implemented independently of each other and share 
neither an inventive concept (Rule 1 3.1 PCT), nor special technical features (Rule 
13.2 PCT). 
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V. Reasoned statement under Rule 66.2(a)(ii) with regard to novelty, inventive 
step and industrial applicability; citations and explanations supporting such 
statement 



I 



The following documents have been considered for the purposes of this report: 

D1: WO 94 28683 A 
D2: US-A-5 530 909 
D3: EP-A-0 757 500 
D4: WO 97 36405 A 
D5: GB-A-2 297 457 
D6: EP-A-0 835 009 
D7: US-A-5 790 936 
D8: EP-A-0 804 006 

D9: PROCEEDINGS IEEE INFOCOM. THE CONFERENCE ON COMPUTER 
COMMUNICATIONS, US, NEW YORK, IEEE, 1998, FIGUEIRA ET AL: 
"REMOTE-QUEUEING MULTIPLE ACCESS (RQMA): PROVIDING 
QUALITY OF SERVICE FOR WIRELESS COMMUNICATIONS", pages 307- 
314, XP000854206 

D10: COMPUTER NETWORKS AND ISDN SYSTEMS, NL, AMSTERDAM, vol. 
29, no. 5, 1 April 1997, CHENG L: "Quality of services based on both call 
admission and cell scheduling", pages 555-567, XP004059227 



II 



1 . The present vague and broad formulation of independent method claim 1 is such 
that its subject-matter can be read onto the prior art disclosure of Document D1 . 

Document D1 indeed already discloses a method for selecting a signal having an 
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appropriate quality of service characteristic from a selection of signals having 
different quality of service characteristics (cf. passages denoted in the 
international search report). 

The essence of the invention is therefore already known from D1 . 
As this document identically discloses all the features of independent claim 1 , the 
subject-matter of this claim lacks novelty and claim 1 does not meet the 
requirements of Article 33(2) of the PCT. 

1b. It should be noted that even if the Applicant were to amend claim 1 in such a 
manner as to enable him to allege that its subject-matter were novel, based on 
minor differences between the features of this claim and those disclosed in 
documents D1 or D2, the subject-matter of claim 1 would still not involve an 
inventive step, Article 33(3) of the PCT, having regard to the disclosure of D1 and 
D2 especially as these documents disclose the same object and the same type of 
solution as claimed in this claim. 



2. Independent claims 7, 13 and 15, although phrased as apparatus claims, are 
nonetheless a simple repetition of the subject-matter of claim 1 and hence do not 
meet the requirements of the PCT for the same reasons. 

3. The dependent claims 2 to 6, 8 to 12 and 14 do not seem to contain any subject- 
matter which, in combination with the subject-matter of the claim on which they 
are dependent, would lead to a claim involving inventive activity (Article 33(3) of 
the PCT). 

Their subject-matter is indeed either directly derivable from the above-cited 
documents or concerns simple embodiments without inventive merit in 
themselves. 
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VII. Certain defects in the international application 

1. To meet the requirements of Rule 6.3(b) PCT, the independent claims should be 
properly cast in the two-part form, with those features which in combination are 
part of the prior art, being placed in the preamble. 

2. To meet the requirements of Rule 5.1(a)(ii) PCT, documents D1-D10 should be 
identified in the description and the relevant background art disclosed therein 
should be briefly discussed. 

3. Reference signs in parentheses should be inserted in the claims to increase their 
intelligibility, Rule 6.2(b) PCT. This applies to both the preamble and 
characterising portion. 

4. In order to fulfil the requirements of Rule 5.1 (a)(iii) PCT, the description should be 
brought into conformity with the new claims. 

Furthermore, following from the disclosure of documents D1-D10, the statement 
indicating the technical problem to be solved by the invention requires a revision 
which should be effected taking the requirements of Rule 5.1(a)(iii) PCT into 
account. 



5. Moreover, the vague and imprecise statement in the description, on page 66, last 
paragraph, implies that the subject-matter for which protection is sought may be 
different to that defined by the claims, thereby resulting in lack of clarity of the 
claims (Article 6 PCT) when used to interpret them (see the Guidelines, C-lll, 
4.3a). This paragraph should therefore be deleted. 
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VIII. Certain observations on the international application 

1 . The various definitions of the invention given in independent apparatus claims 13 
and 15, are such that the claims as a whole are not clear and concise, contrary to 
Article 6 PCT. The claims should be recast to include only the minimum necessary 
number of independent claims in any one category (Rule 6.4(a)-(c) PCT). 

In the present case it is considered appropriate to use only one independent claim 
in any category. 

Claim 15 is indeed a tautology of claim 13. 

2. The independent claims 1 , 7 and 13 do not meet the requirements following from 
Article 6 PCT taken in combination with Rule 6(3)(b) PCT that any independent 
claim must contain all the technical features necessary to the definition of the 
invention. 

It is not understood from the present formulation of the independent claims which 
component of the network is in charge of selecting. It is not understood either 
which part of the network is in charge of evaluating the quality of the different 
channels. Where are the results of the evaluation kept, in a table? 

At the moment, the formulation of method claim 1 ("...selecting a radio flow having 
appropriate quality of service....") is even so vague that the scope of protection 
comprises the case where the selection could be done by a human being who 
would measure manually all the different channels and select the best one: this 
feature is therefore not even technical. The scope of protection is therefore not 
even supported by the description (Article 6 PCT). 

The formulation of the apparatus claims is also very vague in that it intends to 
define a system with " a selection of predefined radio flows". However, this feature 
is not a structural feature of an apparatus. What should be found in an apparatus 
claim is where this selection is made and kept (in which part of the system) and 
how (are the different quality of service characteristics of the different possible 
communication channels kept in a table?). The apparatus claims therefore also do 
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not contain all the essential technical features and are unclear as to their category 
because defining an apparatus with features which are not structural (Article 6 
PCT). 
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WO 00/13436 l^F PCT/EP99/07718 



A method and system for supporting the quality of service in wireless 
networks 

5 

The present invention relates to a mechanism for supporting the quality of 
service in radio networks. In particular, it relates to a method, system and 
communication devices which support the quality of service in packet data 
10 transmission in a radio network. 

Such a mechanism is required, for example, in wireless internet protocol (IP) 
networks. 

is The term "Internet" is commonly used to describe an information resource 
from which information can be retrieved from a data processor, such as a 
personal computer (PC). The data processor communicates via a modem with 
a telecommunication network. This information resource is distributed 
worldwide, comprising several storage locations which also communicate with 

20 the telecommunication network. The Internet is made operable by defining 
certain data communication standards and protocols, such as TCP (transfer 
control protocol), UPD (user datagram protocol), and IP (Internet protocol), 
which are used for controlling data transmission between numerous parts of 
the Internet. The TCP and the UDP are involved with preventing and 

25 correcting data transmission errors in the data transmitted in the Internet; the 
IP is involved in packet addressing and routing. The currently specified 
versions of the Internet protocol are IPv4 and IPv6. IPv4 is defined in 
RFC791 and IPv6 is defined in RFC1883. 
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Thanks to the growing popularity of open data systems, the Transmission 
Control Protocol/Internet Protocol (TCP/IP) communication protocol has 
become a generally used protocol whereby computers of different sizes and 
brands can communicate with each other. TCP/IP support is currently 

5 available for almost all operating systems. The network layer protocol of 
TCP/IP, the Internet Protocol IP, is intended to be used for packet routing by 
gateways, i.e. routers. The routing is conducted by means of IP addresses of 
four bytes and routing tables. Thanks to the Internet protocol, computers 
using the TCP/IP can transfer messages in the routing network even to the 

io other side of the world. 

The rapid evolution of the Internet services has created a strong need for 
broadband networks with high data rate and Quality of Service (QoS). Video 
broadcasting and other multimedia distribution services are evolving rapidly. 

is The users are willing to access these services also in the wireless 
environment. Currently, in the fixed IP network, IP packets are typically sent 
as best effort data traffic. In the case of network congestion, all data streams 
are handled with equal priority which may have a dramatic effect on 
multimedia services. Two main problems exist: firstly the current wireless 

20 networks will not provide sufficient QoS mechanism, and secondly, the 
existing wireless networks are not capable of serving several simultaneous 
connections with high data rate and QoS requirements. To meet the 
increased customer requirements, new wireless broadband network 
techniques are required. 

25 The Internet Engineering Task Force (IETF) is an organisation involved with 
the development of internet architecture and operation in the internet. They 
have defined two different IP based QoS concepts: integrated and 
differentiated services, for providing a standard mechanism for supporting real 
time applications in IP networks. Integrated services is based on an abstract 
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flow model with reservation protocol (RSVP, RFC2205) and admission 
control. The network reserves statically resources for real time connections in 
each network device, and hence is not optimally efficient. Consequently the 
differentiated services concept was developed. This concept is based on the 
5 use of an IP header for indicating the requested service class for the packet. 
As a result, each IP packet header carries QoS information and no static 
reservations are required. Whilst the IETF suggest the use of an IP header 
for indicating the QoS, the actual packet handling mechanisms will not be 
standardised. 

10 The present invention provides a wireless IP network architecture which 
supports QoS, and in particular differentiated services in the air interface. 

According to a first aspect of the present invention, there is provided a 
method for supporting the quality of service in packet data transmission in a 
radio network, whereby transmission over the air interface is in radio flows, 
is the method comprising selecting a radio flow having appropriate quality of 
service characteristics for the packet to be transmitted over the air interface 
from a selection of predefined default radio flows having different quality of 
service characteristics. 

The provision of default radio flows enables the radio network to support 
20 differentiated services, and thus cater for wireless broadband services. In 
particular, it prevents bottlenecking of data in the radio part of an IP network. 

Radio flow selection may be effected by providing the packet to be transmitted 
with a radio flow identifier selected from predefined default radio flow 
identifiers representative of different quality of service characteristics. The 
25 packet may then be mapped into the identified default radio flow for 
transmission over the air interface. 
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Advantageously, the method comprises detecting handover of a mobile 
communications device having an active connection from one radio 
subnetwork to another and performing default radio flow selection for the 
active connection in response to handover detection. 

5 

This further improves inter-domain mobility. For example, as a mobile 
terminal moves into a new radio subnetwork (e.g. the area of a new mobile 
router), the default radio flows can be utilised for improving the performance 
of the handover. The new router will typically have no information of the 

10 terminal connections and requested QoS. Therefore, it cannot establish QoS 
flows in advance. In order to reduce packet losses during the handover, the 
terminal and network can temporarily switch the existing connections ("old 
flows") into one of the default radio flows. This approach allows the 
assignment of a higher QoS for certain connections until the new router 

is detects QoS ( IP) flows and switches the connections into separate radio 
flows. 

Preferably, the method also supports integrated services. For example, in a 
preferred embodiment of the invention, the method further comprises 
20 monitoring packets to be transmitted over the air interface to detect IP flows, 
and switching a detected IP flow to a dedicated radio flow having 
corresponding quality of service characteristics. Typically, a default radio flow 
will initially be selected, and then an IP flow will be transferred to a separate 
radio flow once that radio flow is set up. 

25 

Switching the detected IP flow to a dedicated radio flow may be effected by 
providing the packets of a detected IP flow with an identifier of the dedicated 
radio flow, and mapping the packets of the detected IP flow into the identified 
dedicated radio flow for transmission over the air interface. 
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A system and communication devices are provided which implement the 
aforementioned method. 

For example, according to another aspect of the present invention, there is 
5 provided a radio access system for supporting the quality of service in data 
packet transmission over the air interface, the system comprising a selection 
of predefined default radio flows having different quality of service 
characteristics, and means for selecting a radio flow having appropriate 
quality of service characteristics for the packet to be transmitted over the air 
10 interface from the selection. 

The radio flow selecting means optionally comprises means for providing the 
packet to be transmitted with a radio flow identifier selected from identifiers 
corresponding to the predefined default radio flows and means for mapping 
15 the packet into the identified default radio flow for transmission over the air 
interface. 

Also, the system preferably comprises means for detecting handover of a 
mobile communications device having an active connection from one radio 
20 subnetwork to another. In this event, the selection means selects a default 
radio flow for the active connection in response to handover detection. 

Advantageously, the system further comprises means for monitoring packets 
to be transmitted over the air interface to detect IP flows, and means for 

25 switching a detected IP flow to a dedicated radio flow having corresponding 
quality of service characteristics. The switching means may comprise means 
for providing the packets of a detected IP flow with an identifier of the 
dedicated radio flow, and means for mapping the packets of the detected IP 
flow into the identified dedicated radio flow for transmission over the air 

30 interface. 
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According to a further aspect of the present invention, there is provided a 
communication device for use in a system which supports the quality of 
service in data packet transmission over the air interface and comprises a 

5 selection of predefined default radio flows having different quality of service 
characteristics, wherein the device is arranged to select a default radio flow 
having appropriate quality of service characteristics for the packet to be 
transmitted over the air interface from the selection. The communication 
device may, for example be a mobile communication device, an access point 

10 controller or a mobile router. 

According to an embodiment of the invention a radio modem provides a few 
different service types, which enables the radio network to support 
differentiated services, and thus cater for wireless broadband services. In 

is particular, it prevents bottle-necking of time-critical data in the radio part of the 
Internet access network. The selection of the radio QoS class may be effected 
by defining the IP type of sen/ice bits, i.e. diffs. bits and selecting the 
corresponding predefined default radio QoS class. The packet may then be 
mapped into the identified default radio queue for transmission over the air 

20 interface. 

The transmission over the air interface can be based e.g. on radio flows, the 
method comprising selecting a radio flow having appropriate quality of service 
characteristics for the packet to be transmitted over the air interface from a 
25 selection of predefined default radio flows having different quality of service 
characteristics. Alternatively, the system may utilise several radio level 
service queues with different scheduling priorities. 

As mentioned above, the presented method comprises detecting handover of 
30 a mobile communications device having an active connection from one radio 
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subnetwork to another and performing default radio flow selection for the 
active connection in response to handover detection. 

This further improves inter-domain mobility. In such an embodiment of the 
5 invention, the new router can immediately notice the required type of service 
by reading the IP header of the incoming packets. Consequently, the real- 
time data can be directly mapped to the highest service class queues which 
will reduce packet losses during the handover. If default radio flows are used 
this approach allows the assignment of a higher QoS for certain connections 
10 until the new router detects QoS (IP) flows and switches the connections into 
separate radio flows. 

Preferably, the method of this embodiment also supports integrated services. 
For example, the method may further comprise monitoring packets to be 
15 transmitted over the air interface to detect IP flows, and switching a detected 
IP flow to a dedicated radio service queue having corresponding quality of 
service characteristics. 

According to another embodiment of the present invention, there is provided a 
20 radio access system for supporting the quality of service in data packet 
transmission over the air interface, the system comprising a selection of 
predefined default radio service queues. The different queues will be 
scheduled differently in the air interface. The packets belonging to a certain 
queue may be transmitted over the air interface either by using a specific 
25 radio flow identifier or alternatively different service queues may be scheduled 
differently but sent without any flow specific identifier. The radio queues 
having different quality of service characteristics, provide means for selecting 
a radio service class which corresponds to the network level, e.g. IP, QoS 
class for the packet to be transmitted over the air interface from the selection. 

30 
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The system of this embodiment may comprise means for detecting handover 
of a mobile communications device having an active connection from one 
radio subnetwork to another. In this event, the selection means selects an 
appropriate radio QoS class, i.e. scheduling queue and/or radio flow for the 
5 active connection in response to handover detection. 

Embodiments of the present invention will now be described, by way of 
example, with reference to the accompanying drawings, of which: 

io Figure 1 illustrates a GRAN Reference Model; 

Figure 2 illustrates a General System Architecture; 

Figure 3 shows target operating environment and transmission link 
alternatives; 

Figure 4 gives an overview of the data path architecture; 
15 Figure 5 illustrates transmission link alternatives; 

Figure 6 shows an Ethernet based system architecture; 
Figure 7 shows the data plane for ATM; 
Figure 8 shows the data plane for Ethernet; 

Figure 9 illustrates an exemplary structure of a radio access network identifier 
20 (RANJD); 

Figure 10 illustrates packet encapsulation if an ATM transmission link is used; 
Figure 1 1 illustrates flow mapping in the case of an Ethernet transmission link; 
Figure 12 outlines of the defined flow management scheme; 
Figures 13 and 14 illustrate an IP and radio flow multiplexing scheme ; 
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Figure 15 illutrates the system architecture and main interfaces; 
Figure 1 6 fives an example of different flow types; 
Figure 17 illustrates typical WFMP tables; 

Figure 18 shows mobile router (M-router) WFMP routing for downlink packets; 
5 Figure 19 shows M-router WFMP routing for uplink packets; 

Figure 20 illustrates transmission between two mobile terminals; 

Figure 21 illustrates the mobile terminal side WFMP operation for the uplink; 

Figure 22 illustrates the mobile terminal side routing for the downlink; 

Figure 23 illustrates a flow compression (FC) structure; 
10 Figure 24 illustrates Integrated Services; 

Figure 25 illustrates Differentiated services; 

Figure 26 illustrates Port information; 

Figure 27 illustrates H.323; and 

Figure 28 shows a Wireless QoS driven queuing and error control strategy. 

is A wireless IP network architecture of a preferred embodiment of the invention 
will now be described, which enables efficient mobile access to both narrow- 
band packet data services and to delay-sensitive broadband multimedia 
services. Firstly, the system architecture will be described, including the 
network structure, data plane architecture, and IP flow management and 

20 architecture. 



Firstly, the general system architecture defining the main physical blocks, 
protocol framework and the main internal interfaces will be discussed. Then, 
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the functionality and interworking of defined functional entities and protocols 
will be illustrated. 

Network Structure 

Theoretical Reference model 

5 The system architecture follows the outlines of the theoretical General Radio 
Access Network (GRAN) reference model, illustrated in Figure 1 of the 
accompanying drawings [ES21]. A broadband radio access network 1 
(BRAN) includes a radio access network 2 (RAN) and core network 
dependent interworking functionality (IWF) blocks. The RAN holds all the 

10 radio dependent parts and the IWFs link RAN to various core networks 3 and 
terminal entities 4. Hereafter in the description, the term preferred system 
generally refers to the entire BRAN network covering RAN and necessary 
IWFs. The preferred system is connected to the IP core network. 

15 Network Entities 

The broadband radio access network depicted in Figure 2 is composed of a 
radio access network 2 having mobile terminals 4, access points 51, 51 5 and 
an air interface between, plus a mobility enhanced IP router 52(M-Router). 
The BRAN is connected to the core IP network which comprises the internet 
20 backbone 21 and home agents 22. 

The radio access network 2 (RAN) implements all the radio dependent 
functionality such as radio resource management, setup and release of 
wireless flows, handovers and packet compression. It contains mobile 
terminals and access points. The mobile terminal 4 is the user's 
25 communication device for accessing wireless Internet services, and is the end 
point of the Internet and radio access network control protocols. The access 
point 51,51' implements all the radio dependent control functionality, such as 
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radio resource management. It includes radio resource management and 
radio link control functions. The corresponding network elements in GSM are 
the base transceiver stations (BTS/TRX) and base station controller (BSC). 

The M-Router 52 creates the wireless IP sub-network forwarding data to one 
5 or more access points. Alternatively, the M-Router may handle the mobility 
and location management of the terminals that are registered to the access 
points 51,51'. The M-Router provides IP mobility services, such as DHCP 
(dynamic host configuration protocol). DHCP is used for allocating IP 
addresses for the terminals. Corresponding element in the GSM network is 
10 the gateway GPRS support node (GGSN). The access points 51, 51' and the 
terminals 4 with an IP stack that belong to the same IP sub-network (use the 
same M-ROUTER) create a logical link. 

The core network 3 comprises a home agent 22 which resides in the home 
network of an associated terminal 4 and is accessed through standard IP 
is gateways. Typically home agent 22 is implemented as part of the M-Router 52 
of the home network. However, it can also be a separate entity (e.g. PC host). 
The home agent 22 can contain user authentication information and a billing 
data base. It resembles the home location register (HLR) in GSM. 

Target Environment 

20 This preferred system of the invention may be used for private and public 
networks. Public networks are typically operated by Internet service providers 
or telecom operators. Common places for public wireless access network are 
hot spots, such as airports, hotels, railway stations etc. In this case the public 
network operator has to be able to reliably authenticate the users for billing 

25 purposes. In addition the network should offer security on IP level. 

Business local area networks (LANs) provide another interesting application 
area for the system of the present invention. Here the system provides a 
wireless extension for the existing fixed LAN infrastructure. Typical company 
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LANs are based on Ethernet cabling. Therefore, in such an implementation 
the access points may be connected to the M-Router 52 via Ethernet. The M- 
Router can serve both fixed terminals and the mobile terminals 4. Figure 3 of 
the accompanying drawings illustrates various transmission link alternatives. 



Data Plane 

The general architecture of the system at the OS I data layer level will now be 
described. 

In the preferred embodiment of the invention, the M-Router 52 has a full 

10 TCP/IP stack functionality. It performs standard IP routing forwarding packets 
to the RAN interface and may embed wireless specific control functions such 
as radio flow control and terminal management functions. The incoming IP 
packets may be classified in the M-Router 52 as will be explained further 
below, in accordance with the invention. The M-Router 52 relays the 

15 incoming IP packet flows via the corresponding access point to the mobile 
terminal using the suitable QoS characteristics. The wireless extension 
controls radio flows, terminal mobility and location management. The M- 
Router 52 may control the access points using a specific control protocol. The 
access point 5 multiplexes the IP flows into radio flows. The access point can 

20 be a simple LAN bridge or alternatively implement a complete IP stack 
functionality. In the latter case the access point is capable of classifying the 
IP packet QoS class by reading the IP packet header and can therefore 
perform the mapping of IP QoS class into the corresponding radio service 
queue with the corresponding QoS characteristics, described later in this 

25 invention. The access point 5 segments and re-assembles IP packets into 
segments that fit into radio link packets. The segmentation and re-assembly 
(SAR) blocks handle the segmentation between the mobile terminal 4 and the 
M-Router. 



5 
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The mobile terminal 4 includes all standard TCP/IP entities and wireless 
specific control services. The control messages are transparently sent 
between the M-Router 52 and terminals 4 utilising control functions. Figure 4 
illustrates the data path architecture. 

5 Transmission Link Alternatives 

The system offers alternative physical transmission links for connecting 
access points to the mobile router; e.g. ATM and Ethernet can be deployed. 
Here ATM refers to the physical link without control signalling. In this case 
ATM provides only segmentation and re-assembly and transmission services 
10 for IP traffic. The ATM option is intended for public telecommunication 
networks owned by a public operator whilst, as mentioned above, the 
Ethernet offers an ideal solution for private wireless business LANs. Figure 5 
illustrates these two transmission link options. 

In the Ethernet case the neighbouring access points typically belong to the 
is same Ethernet segment which is connected to the router. The access points 
in the same Ethernet segment have the same IP sub-network address. 
Therefore, they comprise one IP sub-network (called a mobility domain). The 
same router can control fixed network elements that are located in a separate 
IP domain. It is even possible to install access points to different router ports 
20 and to create several mobility domains with different IP network address. 
Figure 6 illustrates the resulting architecture. 

Figure 7 of the accompanying drawings illustrates packet encapsulation in the 
ATM case. In the ATM link the M-Router port identifies the access point 
uniquely. The IP packets are encapsulated into AAL5 frames between the M- 
25 Router and the mobile terminals. AAL5 layer segments the packets into 48-bit 
long ATM cell payload. In this case the access point passes the ATM cells 
transparently to the M-Router. 
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Figure 8 of the accompanying drawings illustrates an example of packet 
encapsulation in the Ethernet case. In the Ethernet link IEEE MAC addresses 
may be used for identifying access points and the M-Router ports. The M- 
Router and the mobile terminal encapsulate IP packets inside Ethernet 

5 frames. Before packets are passed into Ethernet layer they are passed 
through an IP/Ethernet convergence layer. This convergence layer verifies the 
IP packet header and the requested IP QoS and maps the packets into the 
corresponding RAN queues. The dedicated flow label may be added 
between the IP packet and the Ethernet header and its concept is the subject 

10 of a published Finnish patent application FI980191. Its content is 
incorporated into the present application by reference. The convergence 
layer marks the IP packets with radio access network specific RAN identifier 
(RANJD). In the case of ATM the RANJD may correspond to the VPI/VCI 
value while the Ethernet may use a random identifier allocated by the M- 

15 Router. This flow label corresponds to ATM virtual path identifier and thus 
resembles the IETF Multiple Protocol Label Switching (MPLS) concept. The 
flow label is decoded at the access point which multiplexes Ethernet packets 
into correct radio flows. The mapping between radio flows and Ethernet 
frames is done in the convergence layer. 

20 Figure 9 illustrates an exemplary structure of the RANJD and the mapping 
into the radio flows according to an embodiment of the present invention. 

If ATM transmission link is used the flow mapping and the use of the RANJD 
(VPI/VCI) is trivial, and Figure 10 illustrates the packet encapsulation for this 
case. 

25 An alternative Ethernet based approach is to perform the mapping between IP 
QoS and radio QoS directly in the access point. In this case the radio flow 
identifiers are not necessary. The access point and the mobile terminal 
implement IP protocol stack and are thus capable of reading the type of the 
service field of the incoming IP packet header. Based on the requested IP 
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QoS class the access point/mobile terminal multiplexes the data packet into 
the corresponding radio service queue. In this model the various connections 
are not distinguished in the air interface. 

Outline of IP Flow Management 

) 

5 The internet protocol implements a connectionless packet data system. The 
data is carried inside packets, the header of which indicates the correct 
destination address. This transmission scheme does not enable the system to 
separate various connections. The only possibility to detect connections is to 
monitor the IP traffic inside the M-Router 52/mobile terminal 4 and to try to 

10 detect and classify IP packet streams, called IP flows. An IP flow is 
established if two hosts (applications) frequently (or regularly) send IP packets 
between each other. Flow classification is explained in more detail below. 
The network can assign certain QoS characteristics for a flow, which is 
required for multimedia service implementation in IP networks. For instance a 

15 particular flow can be prioritised in the router. 

The mechanism of the invention maintains the QoS characteristics of the IP 
packets in the air interface and permits the prioritisation of different IP packets 
(flows) in the radio link. The concept may deploy radio flows which are 
created between the mobile terminal and the access points. In this case the 
20 specific radio flow identifiers may be utilised. An alternative mechanism is to 
perform direct mapping from the IP type of the service parameters into 
different radio level scheduling queues. The latter approach will not need to 
utilise IP or radio flows. The outlines of the specified alternative flow 
management in the preferred embodiment are as follows: 

25 The M-Router 52 monitors the headers of the incoming. IP packets and tries to 
classify the existing IP flows (i.e. regular packet streams) utilising the IPv6 
flow label and/or destination and source IP/IPv6 addresses and ports. If the 
M-Router detects an IP flow, it will start marking the packets which belong to 
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this flow with a specific RAN_ID (Radio Access Network IDentifier). The router 
allocates a unique RANJD for each detected flow. RANJD is utilised for 
separating packets belonging to IP flows in the radio access network. 
Consequently, the use of RANJD will create "virtual connections" through 

5 which IP flows are packed cross the RAN (MT-M-ROUTER). RANJD 
corresponds to the ATM VPIA/CI identifiers. A wireless flow management 
protocol (WFMP) is disclosed in the aforementioned copending application 
(Annex 1) for managing RAN identifiers. Both the terminal 4 and the M-Router 
52 have WFMP entities which communicate peer-to-peer over the wireless 

10 link. WFMP actually provides the convergence layer functionality. The M- 
Router WFMP detects flows, allocates RANJDs and informs mobile terminal 
WFMP of the assigned ID value. To minimise the overhead the RANJD may 
be compressed into a shorter radio flow identifier. 

As mentioned previously, the radio link is the bottleneck concerning QoS and 
15 the throughput. The present invention addresses this problem in this preferred 
embodiment by providing a system which includes a few radio scheduling 
queues with different service characteristics, which improves the wireless 
support for broadband services. The radio sub-system handles various radio 
queues i.e. radio QoS classes differently. It may have, for example, three 
20 separate buffering queues for the incoming traffic: high priority queue for real- 
time traffic, medium priority queue for non-realtime data and low priority 
queue for best-effort data. Two alternative mechanisms may be used for 
mapping the QoS requirements of the IP packets into the radio level QoS 
functions: direct QoS Mapping or radio flow based QoS mapping of the IP 
25 packets. 

Direct QoS Mapping 

In the direct QoS mapping scheme the access point and the mobile terminal 
classify the header of the IP packets to be transmitted over the air interface. 
All IP packets are treated independently in this approach. The access point 
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or the mobile terminal, i.e. the end points of the radio link, encapsulate the IP 
packet to be transmitted inside the radio link protocol structure. The radio link 
service queue is selected on the basis of the value of the type of the service 
field (diffs. bits) of the original IP packet. Based on this value the IP packet is 
5 mapped into the corresponding scheduling queue, e.g. the real-time, medium 
priority or the best-effort data queue which will have different service 
characteristics and transmission priorities. 

Radio Flow IP based QoS Mapping 

As mentioned above, the system of the present invention may use either 
10 direct QoS mapping or IP flow detection idea for managing connections in the 
radio access network. The idea of IP flow mapping is to separate IP flows 
from the best-effort IP traffic to be able to treat the flows differently. The 
different treatment means that different priorities (QoS classes) can be given 
to the detected flows, and that the detected flows can be compressed to save 
15 the radio resources. 

The present invention concerning flow based QoS mapping resides in the 
provision of fixed channels for different QoS classes. In this embodiment, 
each mobile terminal has three default radio channels: one for best-effort 
traffic, one for medium priority traffic and one for high priority traffic. All the 

20 default channels are terminated at the M-Router WFMP module (n-to-1 
relationship). In addition to the default channels, mobile terminals can have 
detected flows. Figure 16 shows how the different flows are routed inside the 
network. The figure presents a simplified network architecture where two 
mobile terminals are connected to the M-Router through two access points 

25 (only the AP interfaces are shown). Each MT has three different radio level 
QoS queues. M-Router and the mobile terminal side operations are 
explained. 
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In the IP flow based mapping scheme the M-Router establishes flows. The 
system may also enable the mobile terminal to request the M-Router to 
establish a radio flow (RAN_ID) with a given priority for a particular IP flow. 
As the M-Router classifies the IP flow it assigns the corresponding priority 
5 class for the established radio flow. The decision is made on the basis of the 
IP flow type and traffic characteristics. Various radio flow priorities enable 
wireless broadband services. 

Only the detected IP level flows will be switched into separate radio flows. 
The other IP packets are transmitted over the air as best-effort data. The 

10 reference system of this embodiment may define either fixed (hard-coded) 
radio flow identifiers which are used for transmitting non-flow packets or to 
dynamically assign flow identifiers for these flows. The reference system 
offers three multiplexed radio flows per terminal, one for each radio priority 
queue. As mentioned above, these "default" radio flows are provided 

15 according to the present invention for improving the support for inter-IP 
domain mobility and differentiated services. In the scheme of the preferred 
embodiment, the M-Router 52 or the terminal 4 can look at the priority bits of 
a single IP packet and send that with the corresponding radio QoS (priority). 
Then, as soon as an IP flow is detected, the packets can be switched into a 

20 separate radio flow with certain QoS and with IP header compression. Figure 
12 summarises the defined flow management concept for IP flows. The 
detected IP flows are marked with a dedicated RANJD label (in ATM 
VPIA/CI). The access point performs RAM flow-radio flow multiplexing, i.e. 
mapping between RANJD and MVC. The M-Router manages the location of 

25 MTs and updates the routing table if the mobile performs handover between 
access points. The extra benefit of the utilisation of separate radio flows is 
that it allows the application of the IP header compression scheme (FC block 
in figure 12). 
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IP Flow Multiplexing 

Figures 13 and 14 illustrate the flow management procedure for downlink 
5 traffic. The process is as follows: 

The M-ROUTER monitors the incoming traffic continuously. As the amount of 
packets per IP flow (between certain hosts (ports)) exceeds the threshold 
value (per time), the WFMP establishes a RAN flow and allocates new 
RANJD for it. Next the packets belonging to the flow are passed to the 
10 access point via Flow Compression (FC) using the allocated flow specific 
RAN_ID. In accordance with the invention, the IP packets that do not belong 
to any flow are marked with one of three default RAN_IDs for providing 
differentiation. 

The FC entity compresses the IP header of the detected flows and copies 
15 RAN_ID to the resulting packet. In the receiving end the peer FC entity can 
detect the correct source by decoding RAN_ID and assigns the missing IP 
header before the packet is passed to the upper layers. Only detected IP 
flows are compressed. 

in this embodiment, the access point 51, 51' has a conversion table which 
20 maps the MVCs (radio flows) into correct RANJDs. The M-Router 52 
allocates RANJD address space per access point. The packets are then 
transmitted to the M-Router with RANJD "flows". Next, the packets are 
transmitted to the radio link. The default RANJDs are assigned with a fixed 
radio link priority. In this embodiment, three default "pipes" (RANJDs) exist 
25 for user data: real-time flow, non-real time flow and best-effort flow. Of 
course, an alternative number of default channels could be used depending 
on requirements. For example, two channels - high and low priority might be 
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sufficient in some instances, where congestion is not likely to be such a 
problem, and in other circumstances, the separation into a further number of 
QoS characteristics might be required. Each channel or pipe has a pre- 
configured RANJD. The non-flow IP traffic is transmitted within these flows 
5 without any compression. 

The radio of the access point (layers 1 and 2) allocates unique MVC values 
per RANJD. Three default MVC "pipes" exists for the non-compressed traffic 
also in the air interface. The default RANJDs are mapped into the 
corresponding hard-coded MVCs while compressed IP flows are switched into 
10 dedicated MVC connections. Different flows are separated in the in the air 
interface using MVC and terminal wireless MAC addresses. 

In the mobile terminal 4 of this embodiment, its radio modem converts the 
received MVC into the corresponding RAN_ID value and passes the packet to 
the SAR layer which reassembles the data into IP packets still maintaining 
is RANJD information. The compressed flows are then passed to FC which 
identifies the RANJD and adds the correct IP header information. The default 
RANJD traffic is passed directly to the WFMP. 

Protocol Architecture 

The detailed system architecture of the preferred embodiment of the present 
20 invention is illustrated in Figure 15. The main external interfaces are listed in 
the following tables. 



25 
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Table 1: External Control Interfaces 



IF# 


Interface 


Explanation 


1. 


MMC-MMC 


Mobility management messages between 
terminal and M-Router Mobilitv manaaement 
messaging is used as a new terminal registers 
into the network and in the case of handovers. 


2. 


WFMP- WFMP 


Flow management control signalling messages. 
This is used for establishing and releasing radio 
flows. 


3. 


MCP - MCP 


Mobile Control Protocol (MCP) provides a 
reliable peer-to-peer protocol for transmitting 
WFMP and MMC messages between the mobile 
terminal and the M-Router. MCP is used for all 
wireless specific signalling. 


4. 


Radio control 
messages 


Radio control messages are used for 
transmitting radio link control messages. For 
instance terminal association and radio flow 
(MVC level) control signalling is carried here. 


5. 


APCP interface 


Access Point Control Protocol (APCP) is used 
for sending radio link control and radio resource 
management messages between the access 
points and the mobile router 



5 



The external control interfaces define the logical interface between the mobile 
terminal 4 and the radio access network (access points 51, 51 \ M-Router 52) 
and between the radio access network 2 and the core network 3(AP-M- 



WO 00/13436 




PCT/EP99/07718 



Router). The external interfaces have to be standardised, if the target is to 
define compatible standard system which can be composed of devices from 
different manufacturers. 

In addition to the standard interfaces the system has also several important 
5 internal control interfaces, which are listed in the table below: 



Table 2: Internal Control Interfaces 



IF# 


Interface 


Explanation 


6. 


Wireless QoS controller - WFMP 
interface 


This is an internal interface which 
is used for transmitting flow 
establishment requests and QoS 
information between the QoS 
manager and the WFMP. As M- 
ROUTER-WFMP detects a new 
flow it queries the radio link priority 
from the QoS manager. In a real 
implementation QoS manager and 
WFMP can be integrated into a 
single entity which removes 
interface 6. 


7. 


Wireless QoS controller - H.323 
interface 


This interface is used for relaying 
explicit H.323 traffic characters, 
such as delay and throughput to 
the radio link QoS. H.323 control 
signalling is decoded in the mobile 
terminal and the required QoS is 
communicated to the proprietary 
wireless QoS manager. QoS 
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manager will use manufacturer 
specific rules for converting H.323 
QoS into radio flow priority. NOTE: 
H.323 specification defines a 
standard interface to the RSVP. 
This could be also used here 
instead of implementing dedicated 
connection between QoS and 
H.323. 


8. 


Wireless QoS controller - RSVP 
interface 


Wireless specific QoS controller 
interacts with RSVP module for 
obtaining resource reservations 
and converting those into radio 
resource reservations and radio 
QoS. The RSVP module requests 
certain QoS from wireless QoS 
manager via this interface. 


9. 


Wireless QoS controller - MMC 
interface 


This interface is used in the case 
of handovers. The MMC module 
informs the QoS controller about 
the handover and requests QoS 
controller to re-establish wireless 
flows. This establishment request 
is then forwarded to WFMP entity. 
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The system architecture includes the following functional blocks specific to 
the preferred embodiment of the invention: 

QoS - Wireless QoS controller: This entity allocates the radio link QoS for the 
IP packets. QoS controller has an interface to H.323 and RSVP blocks which 

5 can give explicit QoS requirements, such as delay, bandwidth, for the IP flow. 
If no explicit QoS parameters are available QoS manager assigns the QoS on 
the basis of DS field (differentiated services) or on the basis of port 
information (standard applications). As WFMP detects a flow it informs M- 
Router-QoS entity of the evaluated packet throughput, this information can be 

10 also deployed for allocating radio link QoS. The QoS controller transmits the 
allocated radio link QoS values to the WFMP entity which then establishes 
radio flows with selected QoS. The QoS controller can also send QoS update 
messages through WFMP. Using QoS update message QoS controller can 
change the radio QoS value for existing flows. This functionality is useful for 

is instance if H.323 or RSVP parameters change during the connection. 

Mobility Management Controller (MMC): MMC entity is responsible for the 
terminal mobility management. The M-ROUTER-MMC has a database which 
contains information of the registered terminals and their current location 
(access point). During the terminal registration MMC can be used for 
20 authenticating the user. The mobile terminal MMC initialises the handover by 
sending a handover_request message to the M-Router-MMC which checks 
the radio resources in the new access point and requests WFMP to establish 
new radio flows in the new access point and to release the old radio flows. 

Wireless Flow Management Protocol (WFMP): WFMP entity manages the 
25 radio flows. It detects IP traffic and classifies IP flows. As WFMP detects a 
new flow it passed flow information to QoS controller that assigns the correct 
radio link priority for the flow. Next WFMP establishes the radio flow with the 
allocated priority. WFMP allocates RANJDs and updates access point 
RAN ID - radio flow tables. The M-Router includes a master WFMP which 
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classifies the flows and maintains the data base of all the existing flows while 
the mobile terminal includes only a simple WFMP entity that multiplexes the 
RADJDs into correct radio flows. MT-WFMP can request the M-ROUTER- 
WFMP to establish a new radio flow with a given priority. This is the case for 
5 instance if MT-H.323 requests a flow with explicit QoS. Also the inter-router 
handover procedure can utilise this mechanism for quickly setting up flows 
between the mobile terminal and the new M-Router after the handover. 

Mobile Control Protocol (MCP): MCP protocol transmits WFMP and MMC 
messages between the mobile terminals and the M-Router. MMC provides a 

10 reliable mechanism for transmitting control information. MMC implements a 
simple go-back-N type of retransmission protocol. A separate low layer 
protocol was added instead of using TCP/IP in order to guarantee a reliable 
transmission of control messages. TCP/IP will not allow separating control 
messages from the other TCP traffic. Therefore, e.g. in the case of handover 

is the control messages would be mixed with the user data traffic, which causes 
a significant delay for the handover procedure and re-establishing 
connections. The use of MCP allows to prioritise all the control traffic before 
the user data packets. 

Flow Compression (FC) block: The M-Router and mobile terminals include FC 
20 entities which compress the detected IP flows. Flow compression is used only 
for the classified IP flows. The other IP traffic is sent without compression. 

Radio Resource Manager (RRM): Each access point has a RRM entity that 
manages the radio resources of the particular access point. In the present 
system WFMP sends resource queries to RRM each time a new flow is 
25 established. WFMP transmits the requested radio flow priority (allocated by 
QoS) and estimated flow rate (WFMP evaluator). Based on this information 
RRM decides whether the connection is accepted or not. RRM provides a 
mechanism for each access point to dynamically manage the radio resources. 
RRM compares the estimated flow rate to the free capacity of the requested 
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radio flow. If insufficient capacity is available RRM can propose WFMP to use 
lower QoS. If WFMP gets a return QoS value which is lower than the 
requested QoS it can either stop establishing the connection or to continue 
with lower QoS. In the case of IP RRM capacity calculations are mainly based 
5 on the estimated flow rate (M-ROUTER). Only RSVP and H.323 signalling 
provide explicit throughput and delay requirements which can be directly 
mapped into RRM. 

Access Point Control Protocol (APCP): APCP protocol provides a mechanism 
for transmitting control messages between the access points and the M- 
10 Router. ACPC can be located on top of TCP/IP stack which guarantees a 
reliable transmission of control messages. WFMP deploys ACPC for RRM 
queries and for sending flow control information to the radio sub-system. 

The detailed functionality of the system is explained below. 

is IP Flow Management 

As mentioned above, the system of the present invention uses IP flow 
detection idea for managing connections in the radio access network. The 
idea is to separate IP flows from the best-effort IP traffic to be able to 'treat' 
20 the flows differently. The different treatment means that different priorities 
(QoS classes) can be given to the detected flows, and that the detected flows 
can be compressed to save the radio resources. 

The present invention resides in the provision of default channels for at least 
two different QoS classes. In this embodiment, each mobile terminal has 
25 three default radio channels: one for best-effort traffic, one for medium priority 
traffic and one for high priority traffic. All the default channels are terminated 
at the M-Router WFMP module (n-to-1 relationship), in addition to the default 
channels, mobile terminals can have detected flows. If the other end of a 
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detected flow is located at the IP core network, the flow is terminated at the 
M-Router compression module (all flows are compressed). In case the 
correspondent node is another mobile terminal, the flow is switched directly 
between the AP interfaces. Figure 16 shows how the different flows are 
5 routed inside the network. The figure presents a simplified network 
architecture where two mobile terminals are connected to the M-Router 
through two access points (only the AP interfaces are shown). Each MT has 
the default channels (three of them), one flow to the IP network, and one flow 
switched between the mobile terminals. 

10 Next, the WFMP flow management functions are described in detail. Both the 
M-Router and the mobile terminal side operations are explained. 

Flow classification 

WFMP is responsible for flow detection and routing of IP packets between the 
network and mobile terminals/radio connections. The function handling flow 
15 detection is called the flow classifier. Flow classifier decides when IP packets 
belong to a flow and after the decision binds the flow to a radio connection. It 
also needs to detect when a flow terminates and release the corresponding 
radio connection. 

Flow classification works so that WFMP monitors the IP traffic and specific 
20 header fields in order to detect new flows. Depending on the IP and transport 
protocol header fields, the following four different flow types can be specified: 

1 . Flows identified by flow labels (type 1 ) 

2. Flows identified by TCP/UDP port numbers (type 2) 

3. Flows identified by the source and destination IP addresses + the security 
25 parameter index (type 3) 

4. Flows identified by the source and destination IP addresses (type 4) 
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The first option can be applied if the applications are able to use the IPv6 flow 
label to mark the different IP sessions. If such advanced applications are not 
available, and if TCP/UDP port information is available, flow type 2 is 
selected. In case IP encryption is used, the second option cannot be applied 

5 since the port information is encrypted. In such a case, security parameter 
index (SPI) is used with source and destination addresses to identify possible 
flows. If no TCP/UDP port information, flow labels or SPI parameters are 
available, the only option is to look just for the source and destination IP 
addresses and separate flows between hosts (the first two options separate 

10 flows between IP sessions/processes). 

Each flow type specifies the set of fields from the IP packet header that are 
used to identify a flow. The set of the header fields identifying a particular flow 
is called the flow identifier. Depending on the flow type, the flow identifiers 
contain the following fields: 

is* Type 1 : source address + destination address + flow label 

• Type 2: source address + destination address + protocol (next header) + 
source port + destination port 

♦ Type 3: source address + destination address + security parameter index 



20* Type 4: source address + destination address 

WFMP can differentiate between these four flow types, and based on the flow 
classification mechanism bind each flow type to a flow. Three different flow 
classifier mechanisms which may be applied in the present system are: 

• X/Y classifier, meaning X packets (with the same flow identifier) in Y seconds 
25 resulting in a new flow 

• Protocol classifier which simply assigns all TCP packets to flows 



(SPI) 
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• Port classifier, using transport layer port numbers to decide which flows to 



The X/Y classifier is the preferred choice as it is the only one which supports 
flow types 1 and 2 

5 Flow detection criteria 

Typical flow detection criteria for the X/Y classifier are listed in Table 3 X/Y 
classifier recommendations. The table gives values for X and Y in a function 
of different amount of flow space available (in this case the flow space refers 
to the amount of radio connections required). Expected performance means 
10 the portion of packets switched to flows. 

As can be seen, the values are somewhat different in different environments. 
Therefore, it should be possible to change easily the values of X and Y in the 
WFMP implementation. 



bind. 
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Table 3: X/Y classifier recommendations 



Flow ~ o 
space req. ' 


Gateway ' / 


Campus/Enterprise Bac^bi!^^ : ^ 


1K 


Classifier: X = 5 / Y = 1 5 sec. 
Flow deletion delay: 30-120 sec. 
Expected performance: 85% 


Classifier: X = 40 / Y = 40 sec. 
Flow deletion delay: 30-60 sec. 
Expected performance: 79% 


2K 


Classifier: X = 5 / Y = 60 sec. 
Flow deletion delay: 30-120 sec. 
Expected performance: 90% 


Classifier: X = 10 / Y = 45 sec. 
Flow deletion delay: 30-60 sec. 
Expected performance: 89% 


8K 


Classifier: X = 2 / Y = 60 sec. 
Flow deletion delay: 30-120 sec. 
Expected performance: 93% 


Classifier: X = 5 / Y = 60 sec. 
Flow deletion delay: 30-60 sec. 
Expected performance: 92% 


16K 


Classifier: X = 2 / Y = 60 sec. 
Flow deletion delay: 30-120 sec. 
Expected performance: 93% 


Classifier: X = 2 / Y = 60 sec. 
Flow deletion delay: 30-60 sec. 
Expected performance: 95% 


32K 


Classifier: X = 2 / Y = 60 sec. 
Flow deletion delay: 30-120 sec. 
Expected performance: 93% 


Classifier: X = 2 / Y = 60 sec. 
Flow deletion delay: 30-60 sec. 
Expected performance: 95% 


CO 


Classifier: all packets 
Flow deletion delay: oo 
Expected performance: 99% 


Classifier: all packets 
Flow deletion delay: oo 
Expected performance: 98% 
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Since the establishment of a TCP connection always contains at least three 
packets used, and since the flow detection should be based on actual data 
packets, a minimum value of six for X is considered appropriate (third data 
packet triggering the flow detection). The value for Y could be 30 seconds. 

5 Flow deletion 

A flow is deleted after some constant number of seconds of inactivity. When 
flow classifier detects a new flow, it starts the flow inactivity timer. This timer is 
re-started each time a packet belonging to that flow is received. Once the 
timer expires, the flow identifier is removed from the list of monitored packets. 
10 Finally, WFMP releases the flow both from the RAN and the mobile terminal. 

RSVP reserved flows 

When RSVP is used to reserve resources from the network, the M-Router 
RSVP module needs to communicate with the mobility specific modules to 
reserve resources from the radio access network. RSVP module has an 
15 interface to the QoS manager and through this interface it asks the QoS 
manager to check the wireless resources. After converting the RSVP request 
to a QoS class, QoS manager requests WFMP to reserve the connection from 
the AP. This request (identified by flow type 5 inside WFMP) automatically 
triggers flow detection in the flow classifier. 

20 The flow identifier is given by the RSVP in filter spec and session parameters. 
The filter spec consists of the source IP address and source port/flow label 
values. Session contains destination IP address, protocol id and destination 
port values. The information carried by the filter spec and the session 
parameters is given to the WFMP so that it can identify actual data packets 

25 belonging to the RSVP reserved flow. Using this information WFMP can route 
the data packet belonging to a specific RSVP flow to the correct RAN 
connection. It is assumed that the RSVP - mobile IP addressing problem is 
solved. The problem appears if a mobile terminal in a visiting network is 
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15 



20 



25 



identified by the care-of address and RSVP uses the home address. In such a 
case, the flow identifier given by the RSVP does not match to the identifier 
carried by the data packets. Thus, the packets belonging to the RSVP 
reserved flow can be neither identified nor routed to the correct radio flow. 

Like the WFMP detected flow, RSVP flows are monitored by the flow 
classifier. Monitoring is needed to detect when the flow shall be released. 
Another option is that RSVP explicitly releases the flow by sending a 
teardown message to the QoS manager module. QoS manager then informs 
the WFMP to release the flow from the AP. RFC2205 says the following: 
"Although it is not necessary to explicitly tear down an old reservation, we 
recommend that all end hosts send a teardown request as soon as an 
application finishes." Due to this uncertainty, it must be possible to release the 
flow either through RSVP signalling or due to time out (after expiry of an 
inactivity timer). 

Handling of differentiated services packets in the flow mapping approach 

WFMP must be able to detect the requested IP type of service bits (DS field) 
in each IP flow and treat packets belonging to this flow according to the value 
carried in the DS field. Each DiffServ packet is handled separately and, in 
addition, flow detection/monitoring is performed for DiffServ packets to detect 
flows. 

When WFMP receives a DiffServ packet that does not belong to a flow, 
WFMP reads the value of the DS field and selects the correct default flow e.g. 
(best effort/medium priority real-time traffic). WFMP has the knowledge how to 
map between the DS field values and the predefined RAN flows, i.e. default 
flows. This knowledge is configured statically in WFMP to minimise 
interactions with the QoS manager module, i.e. WFMP does not need to 
consult QoS module each time a DiffServ packet is received. 



WO 00/13436 




PCT/EP99/07718 



Flow management at the M-Router 52 

tn this preferred embodiment, the M-Router is responsible for the flow 
detection and management of RAN flow identifiers. It also has an interface to 
the radio access network through which it can create and remove radio 
5 connections, and to QoS manager to retrieve QoS class and bandwidth 
estimates for new flows 

WFMP uses two tables for flow management: active flows table (AFT) and 
default flows table (DFT). The detailed structure of the tables is presented in 
Figure 17. AFT is used to manage all the detected flows, whereas the DFT 
10 contains an entry for each registered mobile terminal. Default flows table 
makes it possible to route non-flow and DiffServ packets to the mobile 
terminals. 

The active flows table has an entry for each detected flow. Depending on the 
flow type, the correct IP header values are stored in the AFT (for flow types 
15 and the corresponding parameters, see Chapter 0). In addition to the IP 
header values, the RAN flow identifier (RANJD) and the AP interface values 
are stored in the AFT. The idea is that once the flow type and the 
corresponding IP header values match, WFMP reads the RANJD and APJf 
values from the table and forwards the packet to the correct RAN flow. 

20 The default flows table is much simpler, it just contains the mobile terminal 
identifier (the mobile terminal IP address) and the RANJD and AP interface 
values. There is one RANJD value for each default flow; RANJD_1 for the 
BE traffic, RANJD_2 for the medium priority traffic and RANJDJ3 for the 
high priority traffic. The values are selected by the WFMP during the mobile 

25 registration. If no entry from the AFT is found for an incoming IP packet, the 
packet is compared against the DFT. Once either the destination or the 
source IP address match to the mobile terminal identifier, WFMP reads the 
correct RANJD (RANJD_1 being the default choice) and AP interface values 
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from the DFT and forwards the packet to the correct radio flow. In case the 
non-flow packet requires a specific handling, RAN_ID_2 or RAN_ID_3 is 
selected. 

• Flow management in the downlink 

5 First, normal IP routing methods are applied and the incoming IP packet is 
routed to the correct IP application/interface. The following rules should be 
followed when routing the IP packets: 

1 . If the packet is addressed to the M-Router itself (e.g. ping), it is processed 
in a normal way 

10 2. Separate RSVP control packets from the other IP packets (identified by 
the RSVP protocol number 46) 

3. Packets addressed to mobile terminals are sent to the WFMP process. 

Next, a detailed description of the WFMP operation is given. 

WFMP needs to select the correct RAN connection for incoming IP packets. If 
15 the packet does not belong to a flow, WFMP just selects the correct best- 
effort channel and sends the packet to the SAR. In case the packet belongs to 
a detected flow, the packet is passed to the compression module which then 
sends the packet to the correct RAN connection. Figure 18 clarifies the 
WFMP routing. 

First, WFMP checks the flow information the incoming packet is carrying. It 
goes through the packet, including the extension headers, and saves all the 
relevant information. From the basic IPv6 header, source and destination IP 
addresses together with the flow label and traffic class (DS field) are saved. If 
the IP packet carries an ESP extension header (Encapsulating Security 
Payload), meaning IP encryption is used, the security index parameter (SPI) 
is saved. In case the packet does not carry the ESP extension header, and 



20 



25 
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TCP/UDP header is found, WFMP saves the port information and the protocol 
identifier. 

After saving the flow information, flow classifier is called for flow detection 
purposes. Flow classifier detects one of the following cases: 

5 

1 . The flow has already been detected, so just the flow information is updated 

2. No flow has been detected yet and just the flow information is updated 

3. Flow detection algorithm decides to create a new flow, starting from this 
particular packet. 

10 When a flow is detected WFMP allocates a new RAN flow identifier for the 
flow. Since no explicit QoS or traffic parameters are available, WFMP has to 
communicate with the QoS manager to get the missing information. When 
requesting the QoS class and bandwidth estimate, WFMP gives the flow 
identifier (information used for flow detection) and TCP/UDP port information 

15 (if available) together with some measured traffic characteristics to the QoS 
manager module. Using this information, QoS manager calculates the QoS 
class and bandwidth estimation for this flow. 

After the QoS manager returns the QoS class and the estimated bandwidth, 
WFMP reserves the connection from the AP and informs the mobile terminal 
20 and the compression module of the new flow. Finally, WFMP updates the 
active flows table (AFT). 

Next, WFMP starts routing the packet to the correct radio connection. In case 
the flow has been detected, the correct RANJD can be read from the active 
flows table (AFT). The correct RANJD is found by comparing the flow 
25 information (according to the flow type) and the flow type to the corresponding 
values in the AFT. When all these fields match, WFMP reads the RANJD and 
the M-Router interface from the AFT and forwards the packet to the 
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compression module. When passing the packet to the compression module, 
also the RANJD must be given. After compressing the packet, the 
compression module sends the packet to the correct RAN connection (given 
by the WFMP). 

5 If no entry from the AFT is found, the packet does not belong to a flow and is 
sent on one of the default channel. The correct default channel is found from 
the default flows table by comparing the destination IP address of the 
incoming packet to the mobile terminaHd values in the DFT. Each mobile 
terminal registered to the network has an entry in the DFT. Once the ids 

10 match (dst_addr = MT_id), flow classifier reads the corresponding RANJD 
(RAN_ID_1 if no special treatment required) and M-Router interface values 
from the DFT and sends the packet to the correct default channel. If the 
destination id does not match to any of the MT_id values in the DFT, the 
mobile is not registered to the network and the packet is discarded. 

is Flow management in uplink 

When a packet is received from the radio access network, it is addressed 
either to a fixed host, or to another mobile terminal. 

According to the RANJD, the SAR layer passes the received IP packet to the 
correct module. This is done automatically since there is a one-to-one 

20 relationship between each RAN connection and one of the modules (identified 
by the SAR SAP). The binding is done when the RAN connections are 
created. If the packet belongs to a flow and the destination is in the core 
network, the packet is passed to the compression module for decompression 
purposes (see Figure 19). In case the packet is non-flow traffic it is passed 

25 directly to the WFMP process. If the packet is RSVP signalling it is sent for 
RSVP module, and so on. 

The uplink WFMP processing is somewhat different from the downlink 
operation; WFMP receives only non-flow packets and 'flow 1 packets 
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addressed to a fixed host. Therefore, the WFMP routing is much simpler 
compared to the downlink case. 

The beginning is, however, similar to downlink operation, i.e. the flow 
information is saved and the packet is passed to flow classifier for flow 

5 detection purposes. The same three cases apply here: (1) flow already been 
detected, (2) flow not detected yet, or (3) new flow detected. If a new flow is 
detected, WFMP needs to select the new RANJD and request the QoS class 
and bandwidth estimation from the QoS manager. Then, WFMP informs the 
compression module of the new id. Also the AP and the mobile terminal must 

10 be informed of the new id, and a new service access point (SAP) added to the 
SAR interface. After the mobile terminal receives the flow information, it starts 
to use the new RANJD for all the packets belonging to that flow. 

Option (1) always means that the correspondent node is located at the IP 
network. This is because mobile to mobile flows are switched directly between 
is the AP interfaces. Options (2) and (3), on the other hand, require specific 
attention. 

In both cases, WFMP has to detect mobile to mobile calls and forward the 
packet to the correct default channel. The correct default channel is found out 
by comparing the destination IP address to the values in the default flows 
20 table. In option (3), the packet is first sent on the default channel (best-effort) 
and only after that the flow is switched. If the destination is located at the IP 
network (not found from the DFT), the packet is sent to the IP forwarding 
process which forwards the packet to the correct network interface (normal IP 
routing applied). 

25 Mobile to mobile traffic 

The start is similar to uplink operation, that is the SAR first forwards the 
packet to the correct process depending on the RANJD. 



WO 00/13436 




PCT/EP99/07718 



In case of non-flow traffic, the SAR sends the packet to WFMP. Since the 
packet is addressed to another mobile terminal, WFMP finds an entry from the 
default flows table. Then it simply forwards the packet to the correct default 
channel (read from the DFT). MT-to-MT non-flow packets are always routed 
5 via the WFMP. 

When the WFMP detects a new flow and the destination is another mobile 
terminal, WFMP creates a connection directly between the two mobile 
terminals. This means that WFMP selects new RAN_IDs for both AP links 
(one for MT1, another for MT2), informs the receiving and sending MTs of the 
10 new ids and adds the new connections to both APs. The compression module 
is not informed since the compression is used between the MTs directly. 
Mobile to mobile routing case is clarified in Figure 20. 

First, the receiving mobile terminal is informed of the new RAN_ID. It then 
sends the acknowledgement back, meaning that the receiver is listening the 

is new RAN_JD. Then, the new RAN_JD is given to the sending mobile terminal. 
The sending mobile terminal understands that the packets belonging to that 
flow must be compressed. It just starts using the new RAN_ID and applies the 
compression mechanism. Finally, the receiving mobile terminal receives the 
first packet carrying the full IP header. It must then save the header since the 

20 consecutive packets are compressed. 

Since the detected MT-to-MT flows are not transmitted through the M-Router 
WFMP module, the WFMP cannot monitor the active flows. This means that it 
cannot detect when the flow should be released. Therefore, the receiving 
mobile terminal side has to control the traffic and inform the M-Router WFMP 
25 when a flow should be released. Possible monitoring places are the MT 
WFMP or MT FC modules. An optional solution is to monitor the traffic in the 
SAR block. The SAR block could measure the traffic going through the 
specific RAN connections (identified by the RANJD) and after a constant time 
of inactivity (time out) SAR would inform the WFMP to release the flow. 
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Flow management at the mobile terminal 

Flow management at the mobile terminal (MT) side is much simpler than in 
the M-Router side. The MT WFMP does not detect flows, it just starts using 
new radio connections when commanded by the M-Router WFMP. 

5 Flow management in uplink 

MT WFMP just needs to pass the IP packet to the correct RAN connection. 
Packets not belonging to a flow are sent on one of the default channels, 
packets belonging to flows to the correct radio channel according to the AFT 
(see Figure 21) Like at the M-Router side, WFMP first updates the flow 
10 information (the same four flow types identified) and uses the correct 
parameters in reading the AFT. If the flow information and the flow type 
correspond to one of the AFT entries, the packet belongs to a flow. 
Otherwise, the correct default flow is read from the default flows table. 

Flow management in downlink 

15 The downlink case is also quite simple (See Figure 22). WFMP does not need 
to do any routing between RAN channels, it just passes the received IP 
packet to the IP forwarding which finally delivers the packet to the correct 
application. Like at the M-Router side, the SAR already takes care of the 
routing by passing the incoming packet to the correct MT process. 

20 Since the M-Router WFMP cannot monitor mobile to mobile flows (flows are 
switched directly between the M-Router AP interfaces, thus bypassing the M- 
Router WFMP), the MT WFMP has to monitor incoming flows. This means 
that when the MT WFMP notices that the flow does not exist anymore, it has 
to inform the M-Router WFMP to release the flow from the RAN. 

25 There are several different mechanisms that could be applied in the WFMP 
flow detection to that described above. For example, the following ideas can 
be used if minimal processing load is required in the M-Router. 
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The simplest mechanism is based on IPv6 flow labels and X/Y classifier. 
WFMP just checks the flow label value, and if it is non-zero uses the source 
IP address and the flow label for flow detection. In case the flow label is zero, 
the packet is treated as best effort traffic and no flow classifier is applied (= no 
5 flows detected for packets having zero flow label). 

Flow compression Scheme 

Header compression may be performed for IPv6 as described in the Internet 
draft on IP header compression by Degermark. The method for grouping IP 
datagrams into compressible streams discussed in the document will not be 
10 implemented. It is assumed that the WFMP module in the M router performs 
the grouping of the IP datagrams on behalf of the flow compression (FC) 
module. 

Every terminal that enters the network is assigned a best effort (BE) channel. 
The datagrams sent on the BE channel are not compressed due to lack of 
15 similarity between individual datagrams. Whenever the M router's WFMP 
module identifies a new flow it sets up a new radio channel for that flow and 
the datagrams sent over the channel are compressed by the FC. 

Whenever an IP datagram is sent either uplink or downlik, a check is made to 
see if it belongs to some flow. If the flow exists, the IP datagram is sent to the 

20 FC module, which performs the header compression and sends the 
compressed IP datagram via the assigned radio channel to its destination. If 
the datagram doesn't belong to any flow, it is sent uncompressed on the BE 
channel. Whenever a new flow is detected, a new radio channel is allocated 
and the FC is notified to set up the compression state and to direct the 

25 incoming datagrams from the radio flow to the FC. When the flow ends, the 
FC is notified so that it may deallocate memory reserved for bookkeeping 
purposes. 
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The header decompression is somewhat simpler than the compression. 
Whenever data is received from a BE channel, it is delivered directly to the 
WFMP. If the radio channel belongs to a flow, the data received is sent to the 
FC which uncompresses and forwards the IP datagram to the WFMP. When 
5 the flow ends, the FC is notified so that it may deallocate memory reserved for 
bookkeeping purposes. 

Even if header compression is done on every non-BE channel it is possible to 
use direct point-to-point flows ("cut-through") between two terminals without 
going through the M router and its FC. 

10 According to the draft proposed in Degermark, the packets are partitioned into 
two different categories, one for TCP and the other for non-TCP packets. The 
packets in each category are further divided into packet streams based on IP 
addresses, port numbers, etc., a task that is already performed by the WFMP 
software module in the M-Router. This partitioning between TCP and non- 
15 TCP packets together with a context identifier (CID) uniquely identifies which 
compressed and uncompressed packets belong to the same packet stream. 
The compression is done by sending oniy those header fields that change, or 
in the case of TCP by sending the change from the previous datagram. The 
draft examines which header fields may be inferred (e.g. packet length), which 
20 are constant, and which header fields have to be either sent as-is or as a 
difference from the previous. 

Four new packet types are defined in addition to the normal IPv6(/v4) packets: 

The full header packet indicates an uncompressed packet that belongs to a 
compressible stream. It includes the context identifier (CID) and a generation 
25 for non-TCP packets coded into the length fields present in the packet 
header. 
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The compressed non-TCP packet includes the CID together with the 
generation and the fields that have changed since the previous full header 
* packet, which is identified by the generation value. 

The third type is the compressed TCP packet that "...indicates a packet with a 
5 compressed TCP header, containing a CID, a flag octet identifying what fields 
have changed, and the changed fields encoded as the difference from the 
previous value", i.e. the previous packet. The TCP checksum is also included 
in the packet. 

The fourth type is the compressed TCP nodelta packet that is similar to the 
10 compressed TCP packet except that the header fields sent as the difference 
from the previous packet are sent as-is. This type of packet is only sent in 
response to a header request issued by the receiver. 

These new packet types are indicated by sending a specific type value either 
on the link layer level or by adding an additional byte in front of the 
15 compressed packet. It is also assumed that the length of the packet is given 
by the link layer. 

The compression is started by choosing a suitable CID value and sending a 
full header to the decompressor. Full headers are sent with an exponentially 
increasing period until an upper time or packet limit is reached. To recover as 
20 quickly as possible from TCP packet errors the decompressor may request 
the full headers for a set of TCP CIDs. The request is sent as a context state 
packet with a list of CIDs which won't decompress correctly which means that 
synchronization is lost between the compressor and the decompressor. The 
compressor replies with a new TCP nodelta packet for each CID requested. 

o 

25 Qos management 

QoS is a new trend in IP-networks. Formerly QoS has been realized by ATM, but 
increasing amount of IP applications (users) demanding QoS from the network, has 
forced network designers to pay attention to QoS in IP networks. 
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The present system is designed to take advantage of customer -and core 
network's QoS mechanisms. Typically, Integrated services based 
mechanisms are seen as QoS mechanisms in the last hop of the network. 
Differentiated services based mechanisms are seen more as core network 
5 mechanisms. Both mechanisms have been considered in developing the 
present system. Also some other mechanisms to separate packets from 
others have been introduced. 

General QoS management concept 

In practice, QoS means differentiating classes of data service - offering 
10 network resources to higher-precedence service classes at the expense of 
lower precedence classes. QoS also means attempting to match the 
allocation of network resources to the characteristics of specific data flows 
[QoS]. These ideas are deployed in the present system. 

QoS can be implemented by differentiating data flows in the basis of different 
is information: IPv6 Flow-ID + source address + destination address, port 
information + source address + destination address, Priority bits + source 
address + destination address, RSVP reservations or H.323. 

These flows can be treated differently from each others, and QoS can be 
implemented by multiplexing these flows in the basis of QoS parameters of 
20 each flow. These parameters can be explicit values (peak cell rate, bandwidth 
requirement etc.) or simply an information of preferred Class of Service. It 
depends on the mechanism how the QoS parameters are determined. 

Packets belonging to a flow, are put to a proper radio queue. In the preferred 
embodiment of the present invention, there are three different queues: Best 
25 Effort, Controlled Load and Guaranteed Service. These flows get different 
priority from each others, and also scheduling inside the queues will be 
performed. 
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QoS Manager (QoS Entity) 

QoS manager's main task is to map fixed network's QoS parameters to radio 
QoS and communicate with radio resource manager. In practice this means 
mapping explicit QoS values to radio priority queues. QoS manager has to 
know some statistics of flow, and proportion this to available radio bandwidth. 
With this information QoS manager can prioritize different flows. 

QoS Manager has interfaces to RSVP, H.323 and WFMP entities (as 
explained above with reference to Figure 15). These interfaces and main 
signals are presented in following table: 



Table 4: QoS manager interfaces 



Interface 


Signals 


M-ROUTER_QoS ->M- 
ROUTER_RSVP 


RESV_FLOW_conf 
RESV_FLOW_req 


MT_QoS ->H.323 
H.323 — >MT_QoS 


SETUP_conf, CLOSE_conf, UPDATE_conf 
SETUP_req, CLOSE_req, UPDATE_req 


M-ROUTER_QOS ' -> M- 
ROUTER_WFMP 

M-ROUTER_WFMP -> M- 
ROUTER_QoS 


RESERVE_FLOW_req 

RESERVE_FLOW_conf 

RR_STATUS_enquiry 


M-ROUTER_QOS -> M- 
ROUTER_WFMP 


UPDATE_req 
UPDATE conf 



M-Router's QoS manager has more functionality than the mobile terminal's 
QoS manager, because flow establishing is performed in M-Router. The most 
important functionalities of the mobile terminal's QoS manager is to assist 
H.323 signalling and handovers. 
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Active flows table 

Active flows table is the place where all information concerning a data flow is 
stored. This table is accessible for WFMP and QoS Manager. As mentioned 
above, an active flows table is exemplified in Figure 17. in addition to 
5 proposed Active Flows Table, QoS information also needs to be included in 
that table, together with an indication whether the flow is signalled or only 
detected by WFMP. 

Ways to get QoS information for a connection 
RSVP (Figure 24) 

10 RSVP is a resource reservation protocol, which tries to reserve bandwidth and 
desired QoS for a particular data flow. This system is readily supported in the 
present system, because flows are detected by WFMP, and flows can be 
treated differently from each others in radio link. RSVP uses control 
messages for marking reservations in intermediate network elements. These 

is control messages are separate from application data. These messages are 
separated from other data in the basis of protocol number, and directed to 
RSVP entity before WFMP process. 

Two different scenarios exist when using RSVP: 

1. WFMP has already detected a flow, and created a dedicated 
20 channel for flow and after that RSVP entity gets reservation request for that 

particular flow. 

2. RSVP entity gets reservation request before WFMP detects the 
flow. In this latter case RSVP should trigger WFMP. This can be done via 
QoS manager. 
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Figure 24 shows how RSVP reservations are handled in the present system. 
This particular picture presents situation where MT is receiver and sender is 
somewhere in network (downlink case). 

RSVP messages (PATH/RESV) use protocol number 46, and that is how 
5 reservation messages can be separated from best-effort traffic. These 
messages will be delivered to RSVP entity which handles them. RSVP entity 
talks with QoS manager which asks WFMP to establish flow with appropriate 
QoS values. WFMP asks resources from RRM, and QoS Manager doesn't 
have worry about this. 

10 In Mobile IP Router, RSVP Entity has two roles, it acts like a normal RSVP 
Daemon, but also makes wireless specific operations. Normal RSVP Daemon 
checks the capacity of the Mobile Router itself, and forwards / manipulates 
RSVP-messages in IP level. Wireless RSVP Daemon communicates with 
WFMP and ask it to establish flows with certain parameters. 

15 RSVP RESV messages can also be so called refresh messages, which are 
sent periodically. These messages shouldn't trigger a new flow, but only 
refresh the existing. This is done in M-ROUTER-WFMP in following way: 

1. RESV refresh message triggers QoS manager to send 
RESERVE_FLOW_req to WFMP. 

20 2. WFMP checks from active flows table if it already has signalled flow for 
that particular dataflow. In the Active Flows table, there has to be an 
indication if the flow is signalled by RSVP or detected in some other basis 
(like traffic volume). 

3 If flow already exists, WFMP only sends confirmation message, and 
25 makes no other actions. 
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Differentiated Services 

Differentiated services means generally deployment of priority bits in every IP- 
header. If WFMP detects a flow of IP-packets with priority, it should inform 
QoS Manager about these bits. QoS Manager includes functionality that 
5 understands the bits, and makes a mapping to required Radio QoS. Pameters 
are marked to the Connection table for that specific flow. 

How parameters are mapped into explicit QoS requirements, depends on 
deployed differentiated services in network side. When the formula of priority 
bits is ready, it's relevant to map the parameters into explicit Priority Classes. 
10 The standardisation of priority bits is still going, and there may be different 
ways to deploy priority bits in the future. Tables 5 and 6 exemplify how bits 
are mapped into priority classes in the preferred embodiment of the invention. 



Table 5 Example of bit pattern 



Bits 


Indication 


Bits 0-2 


000 = Drop Preference 1 , 001 = DP 2, ... ,1 1 1 = DP 8 


Bit 3 


0 = Normal Delay, 1 = Low Delay 


Bit 4 


0 = Normal Throughput, 1 = High Throughput 


Bit 5 


0 = Normal Reliability, 1 = High Reliability 


Bits 6-7 


Reserved for Future Use 



15 Table 6 Example of mapping Priority bits to QoS Classes 



Priority bits 


QoS Class (see Table 8) 


???001?? 


Class 3, BE 


???101?? 


Class 2, Controlled Load 


???1 10?? 


Class 1, Guaranteed Load 



If WFMP detects packets that include priority bits, but can't detect a flow from 
that traffic stream (not enough packets per second), WFMP puts these 
packets to the right priority queues. In other words, WFMP does not ask 
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anything from QoS manager, if packets are only occasional. That is, the 
intelligence is split between WFMP and GoS-manager, so that the QoS - 
manager does not become over deployed. 

Well known ports 

5 There are many "well known" TCP /UDP ports, indicating that traffic needs 
some real time features, or it may also indicate that the amount of traffic is 
extra high or low. This kind of ports are e.g. ftp-port or telnet port, which both 
have very different characteristics. Ftp needs much bandwidth, but it isn't so 
critical with real time requirements. On the opposite, telnet doesn't need much 

10 bandwidth, but it shouldn't get affected by high delay. This information can be 
deployed when choosing the right radio link queue for the data flow. In 
Preferred system, it's relevant to take advantage of port information after a 
flow has already been detected. This means that port information itself doesn't 
trigger WFMP to notice a new flow, but after a flow has been detected, port 

15 information can be deployed. If IPSEC or some other protocol hides port 
information, then it can't be deployed. 

Figure 26 presents a situation, where WFMP has detected a flow and port 
number belongs to an applications that is identified by QoS Manager. 

Table 7 includes some common ports that could be treated differently. Listing 
20 of ports is only an example, and the ports that get specified service, could be 
changed. 



Table 7 Ports (Example) 



Type 


Port number 


Explanation 


Possible QoS Classes 
(See Table 8) 


ftp-data 


20/tcp 


File Transfer [Default Data] 


Class 3 


ftp-control 


21 /tap 


File Transfer [Control] 


Class 3 


telnet 


23/tcp 


Telnet 


Class 2 
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http 


80/tcp 


World Wide Web HTTP 


Class 2 


snmp 


a r* a /x _ _ 

161/tcp 


o k lit i 

SNMP 


Class 3 


ipx 


Z 1 o/ICp 


1 D V 

IrA 


Class 3 


dhcpv6-client 


546/tcp 


DHCPv6 Client 


Class 2 


dhcpv6 


547/tcp 


DHCPv6 Server 


Class 2 


vat 


3456/tcp 


VAT default data 


Class 1 


Vat-control 


3457/tcp 


VAT default control 


Class 1 



The network administrator is preferably able to configure ports that get special 
handling as it is desirable to configure the classification in the basis of what 
customer company needs. Some company may use multimedia applications 
5 much more aggressively than others. Also, some companies may use their 
own specific applications that should get most of the bandwidth (e.g. banks). 
This special treatment is possible, for example, if the QoS Manager is a 
separate functional entity that can be updated easily. 

H.323 

10 In the system of the present invention H.323 can be deployed in two different 
ways: 1) H.323 applications signal connections via the QoS manager, or 2) 
H.323 signals connections by using RSVP (Figure 27). In both cases, there 
also has to be a mechanism to update the connection. 

15 The H.323 call signalling procedures are made of five steps from call set-up to 
call termination. The call set-up procedures with all possible cases are 
complex and are only briefly outlined below. 

Firstly, a SETUP message is sent from the calling endpoint to the other party 
which responds with a CONNECT message. Next, both parties exchange 
20 system capabilities by transmission of the H.245 TERMINAL-CAPABILITY- 
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SET message. During the third phase logical channels for the various 
information streams are opened using H.245. These streams are transported 
over an unreliable protocol specified by H. 225.0. Data communications which 
is transmitted in the logicaf channels set-up in H.245 t are transported using a 
5 reliable protocol (H. 225.0). During a session, the procedures for changing 
capability, receive mode etc. are specified in H.245. 

The bandwidth required for the connection can be determined from the 
capabilities that are agreed to be used between the terminals with a table that 
maps the audio codec selected to the bit rate required by the codec. For video 
10 codec, the maximum allowed bit rate is included in the capability set message 
per available video codec. 

Finally, the call is terminated by either of the parties with an END-SESSION- 
COMMAND in the H.245 control channel. The other party responds with a 
RELEASE-COMPLETE message. 

15 The interface from the H.323 protocol stack to the QoS manager requires 
three functions to facilitate the above mentioned functionality with H.323. The 
required bandwidth with information about the parties (source & destination 
address) must be passed to the QoS manager after the call set-up phase. If 
the required bandwidth between the parties is changed during a call it must 

20 be signalled to the QoS manager as well with an update request stating the 
new bandwidth and identification information for this connection so that the 
QoS manager can identify which connection's bandwidth it has to modify. 
Finally, after the call is terminated the bandwidth must be released by 
signalling the QoS manager that this connection has been terminated. 



25 
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RAN QoS functions. 

The QoS based radio access network has to be able to provide bandwidth on 
demand, class based queuing and reliability. In a wireless transmission link 
multiplexing of different services into the medium typically requires 
5 consideration on four QoS accounts: bandwidth, delay, jitter, and reliability. 

Bandwidth is the first requirement for QoS driven services i.e. to be able to 
support the requested traffic parameters. In the wireless link the main 
objectives are efficient channel utilisation while maintaining service specific 
QoS for TCP/IP traffic. This means that the AP Scheduler should know the 
10 requested average and/or peak bandwidth of those connections for which the 
radio flow is to be established. This way the Scheduler can guarantee the 
satisfaction of bandwidth on demand and perform statistical multiplexing. 

Delay and Jitter are primarily affected by the traffic scheduling over the 
wireless link. In the present approach the flow based connections are queued 

is separately (queue for each connection) and connections are grouped into 3 
different delay class queues. In order to be able to put the packets to the right 
queue, the Scheduler (or queuing function) needs to know the flow ID and 
delay class of the incoming packet. Also, to take the delay and jitter 
requirements into account in choosing the packets to be sent, the Scheduler 

20 should know a) maximum allowed delay of the packets at RAN layer b) keep a 
time stamp for each packet. 

Reliability over wireless link requires error control which is typically given for 
instance by coding and/or data re-transmissions. Coding is used both for the 
error detection and correction which imposes constant overhead over the 
25 applied data. ARQ (Automatic Retransmission reQuest) is only applied for the 
corrupted packets which is feasible as long as the packet loss probability is 
not too high and delay of retransmission is admissible. The scheduler needs 
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information about ARQ usage per radio flow (connection) basis, (e.g. No 
ARQ, Limited ARQ, ARQ). FEC usage can be fixed, used for all packets. 

Table 8 presents an example of mapping from TCP/IP QoS into the radio 
access network specific QoS according to a preferred embodiment of the 
5 present invention. The first two columns specify radio access queuing and 
error control while columns 3-5 show different TCP/IP level QoS concepts. 



Table 8. Example of network QoS mapping into radio access QoS. 



Delay 
Class 


Radio Access 
QoS 


Transmission 
Protocol 


Integrated 
Services 


Differentiated 
Services 


1 st class 


No 

ARQ+FEC 




Guaranteed 
Load 


low 

delay/high 
dropping 


2 nd class 


Limited 
ARQ+FEC 


UDP/RTP flow 


Controlled 
Load 


medium 
delay/ 
medium 
dropping 


3 rd class 


ARQ+FEC 


TCP flow/No 
Flow 


Best Effort 


high 

delay/low 
dropping 



The radio link schedules the packets belonging to various queues (also called 
10 radio QoS classes or delay classes) differently thus meeting the varying delay 
requirements. 

In one embodiment relating to radio flows, the M-Router functions as a central 
intelligence point of the radio access network detecting flows, classifying them 
and mapping network QoS concepts into radio QoS capabilities. An 
is alternative embodiment utilises direct QoS Mapping, in this approach the 
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access point may handle IP packets, check the QoS bits of each header and 
to map the IP packet into the corresponding radio scheduling queue. 

Queuing (See Figure 28): Queuing strategy for priority classes 1 and 2, in the 
preferred embodiment, is based on the radio flows such that each radio flow 
5 has its own queue. Based on the flow ID, the right priority class can be 
chosen as well as the queue where the packet is put. This approach is 
required because the Scheduler has to be able to differentiate the 
connections and their QoS requirements. For Best Effort data (priority class 
3), the flows may also be identified. 

10 Delay and Jitter: These are primarily affected by the error protection scheme 
and traffic scheduling over the wireless link. It has been found that adding 
one more queue improves the service quality that can be provided for Internet 
voice, thus increasing the service differentiation capability. 

Scheduler 

15 The wireless environment puts a special stress also on the performance of the 
scheduling algorithm. This requires a scheduling algorithm that is efficient and 
aware of QoS and traffic characteristics of the connections. 

The scheduling algorithm has an important role in controlling the flow of the 
packets over the band-limited wireless channel. Used together with Call 

20 Admission Control (CAC) and resource allocation, the scheduling can be used 
to guarantee the satisfaction of different QoS requirements for different traffic 
types. Admission Control and resource allocation operate at the time of the 
connection is established, deciding whether new radio flows/connections can 
access to the channel. The scheduling makes the decision on choosing the 

25 packets to each MAC frame. The scheduling algorithm should aim to provide 
the following properties: [Garrett 96] 

• Maintenance of traffic characteristics of the connections 
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• QoS requirements satisfaction - the QoS parameters related to delay and loss 
are important to maintain according to the traffic contract. 

• Statistical multiplexing gain - the scheduling should smooth or take into 
account the effect the connections with variable bit rate have on the buffer 

5 occupancy (congestion). 

• Utilization of bandwidth unallocated or allocated to idle connections - since the 
applications (WWW-browser for instance) may be not sending cells all the 
time, being silent, the unallocated resources should be utilized during these 
periods. 

10 • Declared and real traffic consistency - in the case where the source is 
producing more traffic than it's expected and thus breaking the traffic contract, 
the scheduler should for instance 'drop' the priority of the connection. 

With the queuing scheme of the preferred embodiment, the Scheduler could 
work for instance in the following way: 

is Firstly, the Scheduler prioritizes the packets according to the three priority 
classes. Class 1 has highest priority and class 3 has the lowest priority. 
Scheduler begins to allocate packets pending in the class 1 queues. Inside 
the priority class, the prioritising between packets/flows can be made 
according to delay requirements i.e choosing packet who have least lifetime' 

20 left and so forth. Parallel to this the flows consuming less bandwidth than 
allocated have higher priority. This can be taken into account by using traffic 
policing function such as Token Bucket. When all the packets of the priority 
class 1 have been allocated and there's still room in the MAC frame, the 
Scheduler begins to allocate packets from priority class 2 queues in the same 

25 way as in the class 1 case. After all the class 2 packets have been allocated, 
the Scheduler allocates class 3 packets into the free slots. Class 3 queue 
works as a FIFO (First In, First Out). The scheduling ends when all the 
packets have been allocated or when the MAC Time Frame is full. 
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Mobility management 

Terminal Registration and Authentication 

The terminal performs the IP level registration process when it has been 
powered on. It is also the initial part of an IP level handover. The process is 
5 the same in the terminal's home network and in the foreign networks. 

The process is performed after the link level registration process. The link 
level procedures have already authenticated the terminal and accepted its 
access to the network. The link level entities have also made the terminal a 
member of the all-nodes and solicited-node multicast groups. The solicited- 
10 node multicast address is calculated from the EUI-64 identifier provided with 
the link level registration messages. 

These multicast groups are local to the link that the terminal is currently 
attached to. This means that both the terminal and the M-Router know that 
this terminal belongs to these multicast groups. The M-Router knows to route 
15 packets that are addressed to these groups to this terminal and the terminal is 
able to receive and process these packets. This is why the terminal does not 
perform an explicit join to these groups using the link level multicast 
membership protocol in the beginning of the IP level registration process after 
it has generated its link-local IP address. 

20 When the link level has performed its registration procedures the link level 
informs the upper level entities of its readiness. If this is a power on situation 
the network interface in the terminal becomes into an enabled state. In this 
case the terminal generates its link-local IP address from the information 
provided by the link level (an EUI-64 formatted MAC identifier of the 

25 interface). Normally a host would validate this address by performing 
duplicate address detection procedures before the final assignment of the 
address. However, the MAC identifier has already been verified during the link 
level registration procedures so there is no need to carry out this verification 
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again as the iink-local IP address is generated from that same unique 
identifier. The terminal assigns the link-local IP address to the network 
interface. 

The following actions are performed in both power on situation and in case of 
5 IP level hand over. The host would normally use link level mechanisms to join 
now to the all-nodes and the solicited-node multicast groups. For the reasons 
mentioned above this task is not performed in this environment at this point 
since the task has been carried out implicitly during the link level registration 
procedure. 

10 Once the network interface has been assigned a valid link-local IP address 
the terminal performs Router Discovery actions in order to find its default 
router and possibly to get the network prefixes for its site-local and global IP 
addresses. The M-Router answers to the terminal's solicitation by an 
advertisement and provides the terminal with information on M-Routers link 

is level address as well as its IP address. The terminal updates its default route 
to point to this address. Note that the Router Discovery process is necessary 
even in the home network because the home network prefixes might have 
been renumbered. 

The router may advertise the site-local and global IP address prefixes for this 
20 link in the advertisement. If this is the case the terminal generates its site-local 
and global IP addresses based on these prefixes. Again, the terminal does 
not need to verify the uniqueness of the addresses by duplicate address 
detection procedures since the network interface specific suffix of the 
addresses has already been proven to be unique during the link level 
25 registration process. Also, in this case the terminal will probably not need to 
join to the solicited-node groups of these addresses as these groups are 
potentially the same as the solicited-node group for the iink-local address of 
this network interface. The terminal assigns its site-local and global IP 
addresses to the interface. 
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The bits in the Router Advertisement may also be set so that the terminal is 
required to acquire its site-local and global IP addresses by stateful 
configuration mechanism such as DHCPv6. In that case the terminal sends a 
solicitation to the all configuration servers group on the link in order to find a 

5 server that is willing to serve the terminal. In this environment the server 
would reside in the M-Router. The server responses with an advertisement so 
that the terminal would know the IP address of the server. The terminal sends 
a configuration request to this address and receives the requested addresses 
in the servers reply. The configuration server would probably add the terminal 

10 into the solicited-node groups of these addresses on behalf of the terminal. 
Otherwise the terminal would have to initiate the generic link level and IP level 
multicast group membership procedures in order to join to these groups. In 
any case the terminal must enable the receiving of the packets coming from 
the interface and addressed to these solicited-node groups. The addresses 

is need not to be verified by the duplicate address detection procedures, the 
configuration server and the other entities within the M-Router are supposed 
to know which addresses are valid for the terminal's interface. The terminal 
assigns its site-local and global IP addresses to the interface. 

The stateful configuration mechanism can be optimized further by leaving out 
20 the DHCP Solicit and the DHCP Advertise messages. They are not needed if 
we assume that the stateful configuration server is located in the M-Router, 
whose address we know already from the Router Discovery process. This 
would be a non-standard deviation from the stateful configuration 
mechanisms and may not go in hand with the proposed IP level 
25 authentication methods. 

Addressing Scheme 

IP level addresses are constructed based on the standard address 
configuration methods. The network interface specific part of the IP addresses 
is formed from the link level MAC identifier of that interface. The identifier is in 
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the EUI-64 format. This identifier is verified during the link level registration 
process and is proven to be unique among all the terminals that are attached 
to the same subnet. If the verification fails the terminal is not able to use the 
network. 

5 The terminal's specific network interface's link-local IP address is generated 
from a static well-known prefix and the network interface identifier. The link- 
local address is not verified by the Duplicate Address Detection process. 

The network interface's site-local IP address is formed from the site-local 
prefix received in the Router Advertisement and from the network interface 
10 identifier. The site-local prefix uniquely identifies this subnet within the site 
area. The site-local address may also be acquired from the stateful 
configuration server. In both cases the generated or received address is 
assumed to be valid and no Duplicate Address Detection is performed. 

The network interface's global IP address is either generated from the global 
15 prefix provided by the Router Discovery process and from the network 
interface identifier. The global address may also be received from the stateful 
configuration server. The global address is not verified by the Duplicate 
Address Detection process. 

The information in the M-Router that is used in the terminals' address 
20 allocation process (either stateless or stateful) is managed by methods that 
are outside the scope of this document. It is also assumed that the terminals 
are attached to just one link at a time so that only one M-Router is accessible 
at a time. The addressing scheme deviates from the standard procedures by 
the fact that no Duplicate Address Detection is performed. 

25 Location management (RAN + IP) 

When the terminal has moved to another subnet the link level performs its 
registration procedures. The IP level is informed about this by the link level as 
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described above ( Terminal Registration and Authentication) after which the 
IP level performs its own registration procedures as described in the same 
section. The IP level mobility deviates from the standard with the fact that an 
indication is received from the lower layer each time the subnetwork changes. 

5 Although the potential subnetwork change has been indicated by the link level 
to the IP level, the ultimate fact that the terminal has moved to another subnet 
is deducted from the site-local and global address prefixes acquired from the 
Router Advertisements or from the site-local and global addresses received 
from the stateful configuration server. These new prefixes are compared to 

10 the old ones that were active on this network interface before the movement. 
If the prefixes differ the IP mobility procedures must be activated. 

The terminal uses a special header extension in the terminal originated 
packets when the terminal is away from its home network. The header 
extension is called the Home Address option. The Home Address option 

is contains the home address of the terminal's network interface. This option 
makes it possible for the terminal to use its new global address in the packets' 
source address field so that the packets can more easily penetrate the 
firewalls along the path. The Home Address option is handled by the receiving 
nodes so that the source address of the received packet is replaced with the 

20 address in the Home Address option. This way the ongoing sessions are not 
disturbed even when the active address of the terminal is changing. 

The terminal informs its previous default router of its new global IP address by 
sending a Binding Update to the router. The message is authenticated with 
the IPSEC AH header. The previous router acknowledges the update. The 
25 previous router becomes a proxy for the terminal's previous global address. 
This means that the previous router captures all the packets that are destined 
to the terminal's old global address and encapsulates each of them into a new 
packet and sends it to the terminal's new global address. The previous router 
also disables the allocation of the terminal's old address for the other 
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terminals under its area until the Binding Update expires. When the Binding 
Update expires the previous router will no longer act as a proxy for the 
terminal's old global address. 

The terminal also informs the router in its home network of the terminal's new 
5 global IP address. This is performed by the same Binding Update + AH/ 
Binding Acknowledge + AH transaction as before. The home router now acts 
just as the previous router in the previous case. The only difference is that the 
terminal sends Binding Updates regularly to the home router so that the 
Binding Update never expires. 

10 The terminal informs also all the corresponding nodes it has recently been 
communicating with of its new location. Again it uses the Binding Update + 
AH message. The corresponding nodes update their data structures so that a 
Routing Header is added to each packet that is destined to the terminal's 
home address. The Routing Header contains the new global address of the 

15 terminal's interface. This makes the packet to be routed first to the new 
location of the terminal. There the Routing Header is removed and the packet 
appears as if it had arrived to the terminal interface's home address. As the 
home address is still a valid address of the terminal's interface, the packet can 
be received and processed as if the terminal was in its home network. 

20 

Inter IP subnetwork handover within router 

This means the case when the terminal moves between router ports which 
belong to different IP domains. Here, mobile IP allocates new address but 
flows can be maintained in RAN. In the IP level this kind of handover is 
25 performed exactly the same as in the previous case. 



DHCP v6 
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When a host wishes to acquire a global Ipv6 address and has received a 
router advertisement with the M bit set, the host has to follow the principles of 
stateful address autoconfiguration, i.e. DHCPv6. 

The stateful address autoconfiguration starts with the host, i.e. the client, 
5 sending a DHCP solicit message to the all DHCP agents multicast address in 
order to find one of the site's DHCP servers. The DHCP server replies with a 
unicast DHCP advertise message that contains the server's IP address. 
Thereafter the client sends a DHCP request to the server in order to obtain 
the network's parameters. The server responds with a DHCP reply wherein a 
10 variable amount of parameters are delivered to the client. The client may end 
the DHCP session by sending a DHCP release message to the server which 
then acknowledges the release by sending a DHCP reply. The server may 
also notify the client if some parameters change by sending an DHCP 
reconfigure message. 

The advertise, request, reply, release and reconfigure DHCP messages are 
all unicast messages and may be followed by a variable amount of extensions 
that carry additional parameters between the client and the server. In addition 
to configuring the client's IP address and DNS entries the extensions include 
information about time zones, TCP parameters and other network information. 
The DHCP messages may also be authenticated. 

The server and the client don't have to be on the same link, a DHCP relay 
server may be inserted between them to provide a larger domain served by 
only one DHCP server. 

The DCHP server may attach an client key selection extension to its advertise 
25 message to indicate which security parameter index (SPI) value the client 
should use when authenticating itself to the server. The authentication is 
accomplished by adding a client-server authentication extension to any DHCP 
message. The purpose of the DHCP authentication extension is to provide 
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20 



WO 00/13436 




PCT/EP99/07718 



authentication in the case that the client does not have large enough address 
scope to reach the server from the beginning, i.e. a DHCP relay is used and 
therefore the normal IPSEC procedures can't be applied. The current draft 
assumes that the key used for authentication has to be known by both the 
5 client and the server before the DHCP registration procedure. 

DHCP v6 in subnets 

When DHCP is used to create the global IPv6 address it is very likely that the 
M router doesn't know the newly created global IPv6 address if the M router 

10 and DHCP server are separate entities. The DHCP server has given away an 
IPv6 address with the correct network prefix to the terminal which implies that 
the M router will sooner or later receive IPv6 datagrams destined to this 
address. In order to send the datagrams to the correct terminal via the correct 
VPI/VCI connection, the M router has to perform address resolution according 

15 to the neighbour discovery protocol [Narten98]. The M router simply sends a 
multicast neighbour solicitation on the link, and receives the link layer address 
in the neighbour advertisement sent in response by the terminal that has 
acquired the IPv6 address in question. The M router may thereafter send the 
datagram via the correct connection and add the global IPv6 address to its 

20 lookup tables. 

Interoperation of RSVP with Mobile IPv6 

In Mobile IPv6 a Mobile terminal (MT), which is visiting a foreign link, can be 
addressed either using its Home Address (HA ) or using some of its care-of 
25 addresses (CoAs). Furthermore, if a Correspondent Node (CN) directs 
packets to the MT's HA (or to a stale CoA), the packets are tunnelled to the 
MT via the Home Agent (or a router at a previously visited link). 
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The various modes of addressing the MT raise issues of interoperability in a 
Mobile IPv6 environment, where RSVP ([RFC2205], [RFC2209]) is used for 
network resource reservation. The addressing modes must be taken into 
account when 

5# composing and transmitting RSVP messages, 

• setting up the reservation state in the network nodes, 

• classifying packets when implementing the traffic control, and 

• consulting routing process for finding out outgoing interfaces and becoming 
notified of route changes 

10 

For conveying addressing information in RSVP messages and maintaining 
reservation state at the network nodes two options can be identified: 

1 ) The MT is always identified by its Home Address in RSVP messages 

This straightforward approach stems from the idea that a RSVP PATH 
15 message originated by the sender application (which only knows the MT by its 
HA) would not be changed on its way to the receiver. This means that RSVP 
state at all nodes would need to be enhanced to encompass at least two 
addresses for the MT: the HA and a CoA. This means that the nodes have to 
be informed of the address binding. The HA is needed for identifying the 
20 RSVP session when trying to find a matching path state for a RESV message. 
On the other hand, CoA would be used for packet classification (if any) and 
consultation with the routing process. 

This approach would necessitate changes to all RSVP-aware routers. It would 
also violate the wording in the current specification, which requires that the 
25 destination IP address of a PATH message must be the same as the 
DestAddress of the session ([RFC2205] p. 36). 

2) The MT is identified by its CoA in RSVP messages when the MT is not at 
home 
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As far as forwarding of application traffic is concerned, in Mobile IPv6 
intermediate routers need not be aware of the binding between HA and CoA, 
except for the case of a Home Agent that is tunnelling packets to the MT. The 
same principle can be also applied to RSVP operation. This is facilitated by 

5 the observation that at the routers RSVP reservation state need not be 
maintained across the whole life span of an RSVP session. Instead, when the 
MT is roaming, a new path state can be built along the data path for each new 
CoA without any knowledge of the actual HA. This approach is more 
scaleable as it necessitates changes only at the end systems, while RSVP 

10 processing at the intermediate routers remains as specified in current RSVP 
RFCs. 

To achieve smooth roaming, several message processing extensions and 
enhancements are required at the MT and the CN. These incorporate IP 
address mapping between HA and CoA with the support of IPv6 address 
15 configuration mechanisms and Binding Cache management. 

Option 2) above would seem to be more feasible in operational networks 
having several core network routers. However, In the present system, any 
deviations from standard RSVP behaviour cannot be expected at the fixed 
network nodes. Therefore, option 1) has to be exploited with the assumption 
20 that the MT and the M-Router, which know the bindings between CoA and 
HA, are the only RSVP-aware nodes on the path between MT and CN. 

Summary 

25 The complete system described in the preferred embodiment is based on 
IPv6 or IPv4 network architecture in which the IP packets with time-critical 
data are mapped into the high priority radio scheduling queues, and in which 
non real-time traffic is assigned to low priority queues. The mechanism 
described allows the user/applications to assign different network levels, here 
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IP QoS parameters for various connection types over the radio link. The radio 
link QoS management described supports both integrated and differentiated 
service based IP QoS mechanisms. 

5 However, as will be appreciated by a person skilled in the art, not all the 
components of this system are essential to the invention: some features are 
not required at all, whilst others are only exemplary and thus may be modified. 

The present invention resides in the provision of a system which supports 
10 differentiated services. That is, a system which has a plurality of radio 
scheduling queues or radio flows with different delay and radio QoS 
characteristics. The solution described allows the operator and/or the 
manufacturer of the network to define the mapping between the fixed IP (DS 
fields) and radio QoS according to the desired flow policy of the particular 
15 network. For example, he can dynamically configure the flow class criteria 
(e.g. how many similar packets will be needed for detecting a flow) and assign 
his own policy which defines how the differentiation bits are mapped into the 
default queues. 

20 In the preferred embodiment, the system has three radio scheduling queues, 
high priority service queue for premium class traffic, medium priority service 
queue for assured class traffic and low priority service queue for best effort 
class traffic, and each priority queue has various radio scheduling parameters 
which define these QoS. However, it will be appreciated that the number of 

25 default channels depends on the network requirements, and may alternatively 
be more or less than three. 

As indicated above, differentiated services generally means deployment of 
priority bits in every IP header. In the preferred embodiment, Tables 1 and 2 
30 illustrate priority class bit mapping which could be employed in an IPv6 
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header. The standardisation of priority bits has not yet been effected, and it 
would be clear to a person skilled in the art how this concept could be 
adapted to be used in a different header (for example the TOS octet of the 
header defined in IPv4 or one defined in a future standard). 

5 

Also, in the preferred embodiment, the network entity (M-router 52/access 
point 51/mobile terminal 4) process the IP type of service field and categorise 
the different packets into one of the default radio queues. The packet is 
marked with the flow specific RAN identifier if the IP service mapping is 

10 performed in the router. Then, the mobile terminal/access point decodes the 
RAN identifier and maps the packet into the corresponding radio flow. 
Alternatively, the access point can perform a direct QoS mapping from the IP 
packet header to the radio queue. However, performance of these functions 
is not restricted to these components. For example, the mapping could be 

is performed in the access point controller, or even a single access point if it 
included an IP packet handler. 

Moreover the flow classification used in the preferred embodiment to detect 
an IP flow is not essential to the invention. If IP flow detection is required, 
20 then various other criteria can be used. For example, the flow classifier can 
be dynamically configured by changing the value of the packets/sec detection 
criteria parameter. 

The present invention includes any novel feature or combination of features 
25 disclosed herein either explicitly or any generalisation thereof irrespective of 
whether or not it relates to the claimed invention or mitigates any or all of the 
problems addressed. 
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In view of the foregoing description it would be evident to a person skilled in 
the art that various modifications may be made within the scope of the 
invention. 
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Claims 

1. A method for supporting the quality of service in packet data 
transmission in a radio network, whereby transmission over the air interface is 

5 in radio flows, the method comprising: 

selecting a radio flow having appropriate quality of service 
characteristics for the packet to be transmitted over the air interface from a 
selection of predefined default radio flows having different quality of service 
characteristics. 

10 

2. A method as claimed in claim 1, wherein selecting the radio flow 
comprises providing the packet to be transmitted with a radio flow identifier 
selected from predefined default radio flow identifiers representative of 
different quality of service characteristics. 

15 

3. A method as claimed in claim 2, further comprising mapping the packet 
into the identified default radio flow for transmission over the air interface. 

4. A method as claimed in any preceding claim, comprising: 

20 detecting handover of a mobile communications device having an 

active connection from one radio subnetwork to another; 

performing default radio flow selection for the active connection in 
response to handover detection. 

25 5. A method as claimed in any preceding claim, further comprising: 

monitoring packets to be transmitted over the air interface to detect IP 

flows; 

switching a detected IP flow to a dedicated radio flow having 
corresponding quality of service characteristics. 
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6. A method as claimed in claim 5, wherein switching the detected IP flow 
to a dedicated radio flow comprises: 

providing the packets of a detected IP flow with an identifier of the 
dedicated radio flow; and 
5 mapping the packets of the detected IP flow into the identified 

dedicated radio flow for transmission over the air interface. 

7. A radio access system for supporting the quality of service in data 
10 packet transmission over the air interface, the system comprising: 

a selection of predefined default radio flows having different quality of 
service characteristics; and 

means for selecting a radio flow having appropriate quality of service 
characteristics for the packet to be transmitted over the air interface from the 
is selection. 

8. A system as claimed in claim 7, wherein the radio flow selecting means 
comprises: 

means for providing the packet to be transmitted with a radio flow 
20 identifier selected from identifiers corresponding to the predefined default 
radio flows. 

9. A system as claimed in claim 8, further comprising means for mapping 
the packet into the identified default radio flow for transmission over the air 

25 interface. 

10. A system as claimed in any of claims 7 to 9, further comprising means 
for detecting handover of a mobile communications device having an active 
connection from one radio subnetwork to another; and wherein the selection 



WO 00/13436 




PCT/EP99/07718 



70 



means selects a default radio flow for the active connection in response to 
handover detection. 

11. A system as claimed in any of claims 7 to 1 0, further comprising: 
5 means for monitoring packets to be transmitted over the air interface to 

detect IP flows; 

means for switching a detected IP flow to a dedicated radio flow having 
corresponding quality of service characteristics. 

10 12. A system as claimed in claim 11, wherein the switching means 
comprises: 

means for providing the packets of a detected IP flow with an identifier 
of the dedicated radio flow; and 

means for mapping the packets of the detected IP flow into the 
15 identified dedicated radio flow for transmission over the air interface. 

13. A communication device for use in a system which supports the quality 
of service in data packet transmission over the air interface and comprises a 
selection of predefined default radio flows having different quality of service 

20 characteristics, wherein the device is arranged to select a default radio flow 
having appropriate quality of service characteristics for the packet to be 
transmitted over the air interface from the selection. 

14. A device as claimed in claim 13, which is a mobile communication 
25 device or a mobile router. 

15. A device as claimed in claim 13 or 14, for use in a system as claimed in 
any of claims 7 to 12. 
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16. A method for supporting the quality of service in packet data 
transmission in a radio network, whereby transmission over the air interface is 
based on packet scheduling, the method comprising: 

selecting a radio scheduling queue having appropriate quality of 
5 service characteristics for the packet to be transmitted over the air interface 
from a selection of default radio scheduling queues having different quality of 
service characteristics. 

17. A method as claimed in claim 16, wherein the radio scheduling queues 
10 may be either aggregated in the air interface or identified separately in the air 

interface with the aid of queue or connection specific radio flow identifiers. 

18. A radio access system for supporting the quality of service in data 
packet transmission over the air interface, the system comprising: 

15 a selection of default radio scheduling queues having different quality 

of service characteristics; and 

means for selecting a radio scheduling queue having appropriate 
quality of service characteristics for the packet to be transmitted over the air 
interface from the selection. 

20 

19. A communication device for use in a system which supports the quality 
of service in data packet transmission over the air interface and comprises a 
selection of default radio scheduling queues having different quality of service 
characteristics, wherein the device is arranged to select a default radio 

25 scheduling queue having appropriate quality of service characteristics for the 
packet to be transmitted over the air interface from the selection. 
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